Open dmiklic opened 8 years ago
What is the motivation of the layer system? Internally, we treat the messaging system as flat. And I recently discovered the pygraphviz interpretation of the inter-layer links is not what we want (so needs massaging to use). Would it make sense to drop the layers altogether?
I'll post some example files later today. On 22 Jun 2016 9:35 am, "Damjan Miklic" notifications@github.com wrote:
There are possible issues if CASUs from different layers have same names. One possible solution is to prefix CASU names from other layers with the layer name, but this currently is not parsed correctly by the deployment scripts. I'm working on a quick-fix, but a longer-term solution is necessary.
@rmm-fcul https://github.com/rmm-fcul please provide your thoughts on this. Could you link some of your .nbg files so I can take a look?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/larics/assisi-python/issues/69, or mute the thread https://github.com/notifications/unsubscribe/AHa-l0pdxcDLy5-EliQJo05F0IIwTPWuks5qOPG6gaJpZM4I7hcL .
The problem I'm having is that this file (extension changed because of GitHub limitations) currently generates correct .rtc files, but looks wrong when examined with the dot tool dot -Tpdf fish_virtual_bee_simple.txt > graph.pdf
On the other hand, this file (extension changed because of GitHub limitations) does not generate a correct .rtc file (there are no neighbors in the .rtc), but looks ok when examined with the dot tool.
Yes, any node mentioned in an edge is a member of the overall graph; so our syntax for inter-layer connections causes dot to consider the nodes with a "layer/node" name to be different than the "node" named ones.
What about requiring all nodes to be defined with the "layer/node" syntax? See attached.
On 22 June 2016 at 10:33, Damjan Miklic notifications@github.com wrote:
The problem I'm having is that this file (extension changed because of GitHub limitations) https://github.com/larics/assisi-python/files/327419/fish_virtual_bee_simple.txt currently generates correct .rtc files, but looks wrong when examined with the dot tool dot -Tpdf fish_virtual_bee_simple.txt > graph.pdf
`
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/larics/assisi-python/issues/69#issuecomment-227692033, or mute the thread https://github.com/notifications/unsubscribe/AHa-l0sIawlghi7tEX0ZLc67CxH2_Bo8ks5qOQFsgaJpZM4I7hcL .
digraph simple_3x3 {
subgraph "bee-arena" {
"bee-arena/casu-004" -> "sim-arena/casu-004-sim" [ label = "virtual" ]
"bee-arena/casu-005" -> "sim-arena/casu-005-sim" [ label = "virtual" ]
}
subgraph "sim-arena" {
"sim-arena/casu-004-sim" -> "bee-arena/casu-004" [ label = "real" ]
"sim-arena/casu-005-sim" -> "bee-arena/casu-005" [ label = "real" ]
}
}
some extra example files attached.
most of them have diagrams in the comments explaining what they are trying to do; some have two independent experiments simultaneously, others have a joint experiment with 4 casus. The most complex is dual_real_virtual_98_32.nbg
where we have two experiments deployed, each connecting virtual and real casus.
My preferred short-term solution is the one you have proposed: in multi-layer setups, always prefix the casu name with the layer name. This was not working with the current version of deploy.py
(empty neighborhoods were written to .rtc
files) so I've fixed it with fedfa5d
In the long term, requiring this extra typing is inelegant and error prone, so we should look for a better solution thereforeI'll leave this issue open.
I'm willing to consider dropping the layers alltogether, maybe I started using them before I fully understood how dot/pygraphwiz handles them. However, I feel that as a concept, they do add some semantic clarity to the .nbg files and they might make neighborhood rendering easier. So I wouldn't drop them without carefully considering the pros and cons.
Please do a quick check whether my changes have broken anything for your .nbg
files.
Ideas for how to handle layers, but only require writing <layer/casu>
if inter-layer messages exist:
In either case, the deployment tools could then assume the layers are present.
There are possible issues if CASUs from different layers have same names. One possible solution is to prefix CASU names from other layers with the layer name, but this currently is not parsed correctly by the deployment scripts. I'm working on a quick-fix, but a longer-term solution is necessary.
@rmm-fcul please provide your thoughts on this. Could you link some of your .nbg files so I can take a look?