Algebra Tool Feature Request: Merge tags of merged nodes

[Arminius]

Hello once again,

let me illustrate the issue with a minimal example:
I have two petri nets, each with only one place.
In the first petri net, the place is tagged a and also has one initial marking:

In the second petri net, the place is tagged a|b and has no initial markings:

I would like to use the algebra tool to merge these two nets into one net whose place with the tags a|b and an initial marking. But using this tool, the result is simply equal to one of my input nets, whichever one was the first operand of the merge. Whichever way I merge, some information is lost, either the b tag or the initial marking.

If you're curious as to why I want this, I actually have three petri nets A, B, and an intermediate petri net M. The end result is a merger of and A and B, but M contains the information of which nodes are to be merged, e.g. if A has a node tagged a and B has a node tagged b which I want to merge, I'll add a node tagged a|b to M. I'm building an automated system where it's not feasible for me to merge A and B directly with each other.
Now M does not know anything specific about the nodes in A or B, such as initial markings or firing rates, so I need to retain the information about the actual nodes from A and B while keeping the tagging information from M. Currently, if I merge A with M, I either forget what the actual nodes are or which nodes from B I need to merge with.

[amparore]

Il giorno ven 26 feb 2021 alle ore 12:03 Arminius <notifications@github.com> ha scritto:

Hello once again, let me illustrate the issue with a minimal example: I have two petri nets, each with only one place. In the first petri net, the place is tagged a and also has one initial marking: [image: pic] <https://camo.githubusercontent.com/17007a63d2a13378221602318736d1f5861a3acbd649ed80487483be35ffdd3c/68747470733a2f2f692e70617374652e706963732f38313562663261316232373766313366633138396636663337663730383963632e706e673f7472733d32656130633866373735396633613435653136393761303564363135643635373330363530363863323361333130623338366662323936643338666561316563> In the second petri net, the place is tagged a|b and has no initial markings: [image: pic] <https://camo.githubusercontent.com/f0d222324b745a339a75a2cc8c21ff3c316049a06a92b65e7addca677d38c244/68747470733a2f2f692e70617374652e706963732f35643639363235363034366130343536323239303736653831303434393033662e706e67> I would like to use the algebra tool to merge these two nets into one net whose place with the tags a|b and an initial marking. But using this tool, the result is simply equal to one of my input nets, whichever one was the first operand of the merge. Whichever way I merge, some information is lost, either the b tag or the initial marking.

I think you are right, the algebra tool was designed (I believe) mostly for structural composition - so the initial markings and other properties were not fully defined. Maybe a clear semantics for some of these properties could be defined. Actually, the behaviour should be that, for each shared tag t among the two net operands, algebra builds the cross product of the n1 places tagged by t of net1 with the n2 places tagged by t of net2, resulting with n1*n2 places in the final net. Same for the transitions. So in principle the tool is not "copying" objects, it is always composing (even if it is a 1 x 1 cross product).

If you're curious as to why I want this, I actually have three petri nets A, B, and an intermediate petri net M. The end result is a merger of and A and B, but M contains the information of which nodes are to be merged, e.g. if A has a node tagged a and B has a node tagged b which I want to merge, I'll add a node tagged a|b to M. I'm building an automated system where it's not feasible for me to merge A and B directly with each other.

Is the cross-product behaviour of algebra what you need? In principle, if each tag appears only once in each operand net, you should get basic superpositioning.

Now M does not know anything specific about the nodes in A or B, such as initial markings or firing rates, so I need to retain the information about the actual nodes from A and B while keeping the tagging information from M. Currently, if I merge A with M, I either forget what the actual nodes are or which nodes from B I need to merge with.

I don't fully understand the specification. Does using M as the first operand resolve the issue? Or do you have some information from M and some other from A that you want to combine?

…

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#24>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGLFJEU2366JNBUUJDZXTALTA55XXANCNFSM4YIHVPCA> .

[Arminius]

I don't think a cross-product would address my problem. I do only want a basic superposition, but I don't think I can ensure the constraint that each tag appears only once.

I don't fully understand the specification.
Does using M as the first operand resolve the issue? Or do you have some
information from M and some other from A that you want to combine?

I lose important information if I use M as my first operand. I guess I should use another example, less minimal and closer to my actual problem:
Net A has a place going into a timed transition tagged a:
Net B has a timed transition tagged b going into a place:

Net M consists of a single transition tagged a|b to signify that transition a has to be merged with transition b. M does not know the firing rate of the transition to be merged or even that it is a timed transition, so I represent it as an immediate transition:

If I merge M and A and B, in that order, I get the following:

This is a place going into a transition going into another place, which is roughly want I want, except the timing information on the transition is lost - it has become an immediate transition.

If I merge A and M, I lose the tag b on the transition and I can no longer merge with B.

[Arminius]

Another way of stating what I would have expected: If you merge a node with tags a|b with another node with tags a|c over the tag a, the result should have the tags a|b|c. If the actual node itself is a copy of the node from the first operand, that is fine. Is merging the tags like this feasible?

[amparore]

dear Arminius, unfortunately, algebra is an old tool that I have not written, and I don't know that much. However, I already needed a similar feature some time ago, and I decided to try to add it today anyway. Please, update both the tools in GreatSPN/SOURCES in WSL, and re-download the GUI. You should now see an experimental feature (-g on the command line) that should combine the tags from both operand places/transitions in the result net. --Elvio Il giorno ven 26 feb 2021 alle ore 13:29 Arminius <notifications@github.com> ha scritto:

…

Another way to stating what I would have expected: If you merge a node with tags a|b with another node with tags a|c over the tag a, the result should have the tags a|b|c. If the actual node itself is a copy of the node from the first operand, that is fine. Is merging the tags like this feasible? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#24 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGLFJERVHB6KIAD3CZD3ZTTTA6H2TANCNFSM4YIHVPCA> .

[Arminius]

Wow, I did not expect you to start working on this so quickly!

Unfortunately, if I try this switch to merge net A and net M from my previous example, the algebra tool throws a segmentation fault.

It does work wonderfully with the other example where I merge a node a|b with another node a|c, though.

Could I ask you to look into what's happening with my first example? Net M simply looks as follows:

[amparore]

send me the pnpro file to reproduce the bug Il 27/02/21 15:56, Arminius ha scritto:

…

Wow, I did not expect you to start working on this so quickly! Unfortunately, if I try this switch to merge net A and net M from my previous example <#24 (comment)>, the algebra tool throws a segmentation fault. It does work wonderfully with the other example where I merge a node |a|b| with another node |a|c|, though. Could I ask you to look into what's happening with my first example? Net M simply looks as follows: One immediate transition tagged a|b <https://camo.githubusercontent.com/a29aa3c4b00bdc06349d8bfe349c91447db55529d974a120d94d10ddb7e45473/68747470733a2f2f692e70617374652e706963732f37323430613864386431303134336461336130316432643536336133363234612e706e67> — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#24 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGLFJEW6RFSRW64TV62OU2TTBEBZRANCNFSM4YIHVPCA>.

[Arminius]

Hey, sorry for not responding for a while.
I've gathered the relevant files in a zip archive. The pnpro files were created with the GreatSPN Editor; the other files were generated from those using the tool unfolding2.

[amparore]

the problem should be fixed now. Il 03/03/21 16:05, Arminius ha scritto:

…

Hey, sorry for not responding for a while. I've gathered the relevant files in a zip archive <https://www.dropbox.com/s/36v1x8lpxxeg74c/issue24crash.zip?dl=0>. The pnpro files were created with the GreatSPN Editor; the other files were generated from those using the tool unfolding2. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#24 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGLFJETFMWYAQJZ4JZQA7W3TBZF5FANCNFSM4YIHVPCA>.

[Arminius]

Thanks! Now it works exactly as I imagined it.

Thank you again for making such quick work of this feature request.