Fix rotation of hexagons in block diagrams

[mgjarrett]

What is the change?

Rotate hex patches based on the cornersUp property before plotting for a block diagram.

Why is the change being made?

The rotation was previously hard-coded to assume a "flats up" hexagon block. This is not always the case. A new cornersUp property for the HexGrid class implemented in #1649 allows us to check for the correct orientation of the hexagons.

• Fix plotBlockDiagram() doesn't respect block orientation #1421

---

Checklist

• This PR has only one purpose or idea.
• Tests have been added/updated to verify that the new/changed code works.

• The code style follows good practices.
• The commit message(s) follow good practices.

• The release notes (location doc/release/0.X.rst) are up-to-date with any important changes.
• The documentation is still up-to-date in the doc folder.
• If any requirements were affected, mention it in the release notes.
• The dependencies are still up-to-date in pyproject.toml.

[mgjarrett]

Note: others may be working on parallel solutions to the issues linked in the PR description. I'm just trying to share the bare-bones outline of a path we could take to fix the problem; I'm not necessarily saying this PR needs to be merged.

[john-science]

As I said in the other ticket (#1278), I have am working on a PR that fixes two different HexGrid bugs. I "assigned" that ticket to me to reduce duplicating work. Sorry about that.

I like your property, and haven't looked at your plotting fix yet.

[keckler]

Thanks @mgjarrett for trying these changes! I think there are a couple things that need to be fixed before we can maybe merge it.

Ultimately I think we can make it work, but man this plotBlockDiagram method is frustratingly specific and fragile. In the longer term, it might make sense to split the method into two methods to handle the cases of hexagonal vs cartesian assemblies independently. I think that would make things a lot cleaner. Not asking for you to do this now, just maybe something to think about in a later ticket.

[keckler]

I might also suggest changing the name of the PR, since this PR is mostly about fixing the block diagrams, IMO. #1649 includes the same changes related to the new cornersUp property.

[mgjarrett]

@keckler thanks for the review.

My goal here was just to show in code what the outline of my idea for fixing the problem was; I thought it would be easier than describing it in words. I knew @john-science was working on this issue, so I wanted to wait and see what the code looked like after he finished his work.

Now that he's fixed most of the confusion between flats/corners up, I think it makes sense to change the scope of this to just fixing plotBlockDiagram, as you suggest. I'll take a stab at it when I get a chance today.

[mgjarrett]

@keckler I incorporated your comments; the plots look good now (at least for a flats up block; I don't have a corners up block handy for testing).

I merged #1649 into this branch locally and tested it, and the plotting still works. So once #1649 is merged into main, this PR can be merged with main and it should all work out.

[mgjarrett]

I thought about adding unit tests, but this is mostly plotting stuff that is difficult to test directly.

[keckler]

Thank you for working on this!

[mgjarrett]

Hmm still needs some work for corners up. I think the plotting is right, but the generation of the pin grid is wrong.

[mgjarrett]

Hmm still needs some work for corners up. I think the plotting is right, but the generation of the pin grid is wrong.

I looked into this problem a little more. There's nothing wrong with the plotting code necessarily, it's just that block.autoCreateSpatialGrids() only works if the block is "flats up". I tried to figure out a way to make it work with cornersUp blocks, but the block doesn't know what kind of grid it is going into when the local pin coordinates are auto-created.

Maybe we could check the orientation of the pin coordinates once the block has been placed in a core grid, and then rotate the pins 30 degrees counterclockwise if necessary? It's not a great solution, but it's the only thing I can think of.

[mgjarrett]

this will be superseded by #1926 -- assuming that is going to be merged, I will close this one

[john-science]

this will be superseded by #1926 -- assuming that is going to be merged, I will close this one

Oh, I'm sorry Michael. We made a list of bug tickets yesterday, and I was just going through them, trying to solve the low-hanging fruit.

I just didn't see this PR, and forgot. Sorry!