-
Notifications
You must be signed in to change notification settings - Fork 90
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
plotBlockDiagram()
doesn't respect block orientation
#1421
Comments
Possibly related to a lot of the assumption that most hexagons are flats up - #1278 |
I don't think the block needs to know what kind of grid is inside it, it just needs to know what kind of grid it is in. For a hex grid, the block grid and the pin lattice should be opposites. If they're not opposites, that's an input error. |
I agree with this idea, and it is actually pretty slick. However, if you consider the printed diagrams to be a tool for diagnosing input errors, then maybe relying on the user being correct is not a good idea. Unless, of course, there is another check in place to ensure that the grid and block rotations are appropriate for each other. |
I agree that there should be input validation to ensure the blocks and pins are correctly rotated w.r.t. one another. We don't currently have any such input validation that I know of. |
|
I wonder if the problem is related to the Lines 2371 to 2373 in 9dbe15c
If you have a flats-up super-grid, or the grid on which blocks are assigned, the pins on those blocks will be corners up. But, the grid created by The grid being the wrong orientation is going to influence the locations of the items on that grid, which I assume is what the block plotter is looking at when it makes the patches for the circles |
So... the method This is a default for that won't apply if you have a |
The
plotBlockDiagram()
function appears to always assume that the lattice within the block is "flats-up". This becomes an issue if one has manually defined a "points-up"pin grid. In that case you'll get a print like the following:
The problem lines appear to be in this chunk:
armi/armi/utils/plotting.py
Lines 1283 to 1290 in 8041ad8
Instead of always rotating the hex patch by 30 degrees, it needs to instead be able to interrogate the underlying grid to know the rotation. Unfortunately I think this is a challenge right now, as the block itself doesn't know the type of grid that is in it (that info is stored on the associated block blueprint). Even still, many block blueprints don't actually have a grid attribute even if the block later gets an auto-generated grid. This is related to #730 (comment)
This type of problem could be solved once #1284 is implemented, I would guess.
The text was updated successfully, but these errors were encountered: