[Question] How to prefer a lower or higher layer when multiple layers work for a partition

[keyserj]

Ask your questions
I've got a diagram with some nodes being partitioned: elklive

There are a few instances here where multiple layers can work for the partitions that are selected - I want to add preference for which layer is chosen.

For the top portion of nodes, I want them to prefer being placed in a layer towards the top, and for the bottom portion of nodes, I want to prefer them being placed in a layer towards the bottom, like so:

ELK Version
snapshot (latest/0.9.1?)

Additional context
The alignment option got me excited, but I think that's intended for aligning nodes within a layer (e.g. when nodes vary in size).

I also thought the nodePromotion.strategy might work with a parent node around the top portion with MODEL_ORDER_LEFT_TO_RIGHT and a parent node around the bottom portion with MODEL_ORDER_RIGHT_TO_LEFT... right to left seems to make the nodes prefer the bottom layer, but MODEL_ORDER_LEFT_TO_RIGHT throws a runtime exception. I didn't make this ticket a bug for that because I'm unsure if I'm using it as intended - when I delete most of the bottom portion nodes, LEFT_TO_RIGHT stops erroring but doesn't seem to make them prefer the top layer (elklive - I'd expect c2 to be in same layer as c1, also maybe a separate issue but x1 should be below x12).

[soerendomroes]

The model order node promotion strategies are somehow different than the other promotion strategies and require certain constraint to be true such that edges only lead to nodes that are defined below the target node or are backward edges.

Partition works by trying to add nodes with the same partition in the same layer and moving nodes to succeeding layers if this is not possible.
The other way around: if it is possible to put the nodes of the same partition in the same layer, it will happen.

[keyserj]

The model order node promotion strategies are somehow different than the other promotion strategies and require certain constraint to be true such that edges only lead to nodes that are defined below the target node or are backward edges.

Oh I see, that's good to know. Yeah when I define x1 later than x12, it seems to work as I was expecting. Unfortunately that doesn't work well with partitioning, which gets some value from not needing to know which nodes of the same partition will be above others.

Partition works by trying to add nodes with the same partition in the same layer and moving nodes to succeeding layers if this is not possible.

Hmm I wonder why c1 is not in the same layer as c2 in this elklive then?

[soerendomroes]

Hmm I wonder why c1 is not in the same layer as c2 in this elklive then?

Since the algorithm decided to put it in the same layer as c21, which is also in partition 0.
You can resolve this by making sure that directly connected nodes are not in the same partition.

I could also mark this as a bug/feature request to potentially allow partition to search for the best layer in the partition, but I do not know whether this will be fixed in the next year since there is a workaround.

[keyserj]

You can resolve this by making sure that directly connected nodes are not in the same partition.

This sounds like a pretty complex solution. I'm currently partitioning by node type - with this solution, it seems like I'd have to traverse the graph to calculate the partition for each c node based on their highest-connected depth from p, then calculate partition for each b & x node based on highest-connected depth from s.

I could also mark this as a bug/feature request

This would ideal for me, but this case is also not a huge deal for me. I think it'd be reasonable if you thought this wasn't a case worth handling.