<div dir="ltr"><div dir="ltr">Hi Simon,<div><br></div><div>I think you're right in suspecting 1 and 2 are correct. GReAT makes no guarantees about in which order parts or rules are evaluated. I believe the same .mga file will always produce the same output in GReAT, but even an ->.xme ->.mga roundtrip can break it. Same for input files.</div><div><br></div><div>If it is possible to create an onto mapping from an element in your input model to an element in your output model, I would split the ID into two parts: 1. a hash of the GUID from your input model FCO (maybe combined with attributes that should make the ID different). 2. Create an ID for the GReAT transform itself. Write a tool to crawl your GReAT model and perform a hash. I would sort children by GUID first, then iterate through them and pick out the things that should change the hash. Write this hash into a .h file and include it in your transform with a UserCodeLibrary. Obviously, you must remember or have tooling to run this hashing tool before you compile your transformation.</div><div><br></div><div>Kevin</div><div><br></div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Dec 7, 2018 at 4:35 AM Simon Görke <<a href="mailto:simon.goerke@ils.uni-stuttgart.de">simon.goerke@ils.uni-stuttgart.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello everybody,<br>
<br>
<br>
I have a Great transformation which needs to set an attribute to a unique<br>
(integer) ID. <br>
My key requirement is that, for a given atom/model, the ID is assigned<br>
identical if <br>
a. two successive transformation runs are performed on the same input model<br>
(same rule.exe).<br>
b. the rule is not changed structurally in the graphic modelling, but it is<br>
recompiled (e.g. because some unrelated attribute setting needs fixing)<br>
<br>
What I did is using a global variable which is initialized once to "0" and<br>
increment it after each assignment to the ID attribute.<br>
Unfortunately this assignment is distributed over several rules like so<br>
(hope ascii graph survives mail formatting):<br>
<br>
<br>
/-------------------rule2_matchY_createX ---> setID_of_X<br>
rule1_Init_globalvar_to_0 ----<<br>
<br>
\-------------------rule3_matchZ_createX ---> setID_of_X<br>
<br>
I.e. rule2 and rule3 are parallel rules which contain different matching<br>
patterns but result in newly created atoms of same type "X". <br>
(This is a simplified example - actually my rules are already existing and I<br>
have to add this ID property to them retroactively / rule which create X are<br>
widely spread in the transformation...)<br>
<br>
Obviously, this approach was too naïve wrt the requirement above, i.e. IDs<br>
are NOT ALWAYS assigned deterministically between two successive runs.<br>
I guess there are (at least) two problems with this:<br>
1. matching in rule2 is not deterministic wrt the output sequence of X-type<br>
atoms. Same for matching in rule3.<br>
2. call order of rule2 and rule3 is not deterministic after recompilation<br>
(due to Great c++ code generation being not deterministic). Not sure about<br>
this - maybe great generates the functions top rule first or something?<br>
Then, this would be a non-issue.<br>
<br>
So:<br>
- if only 1. Is correct and 2. NOT, I could merge (serialize) the outputs of<br>
rule2 and rule3 into one rule and try to find a unique property which can be<br>
used for sorting before actually assigning the ID. <br>
Problem here: only one output port can be sorted and the attributes of this<br>
FCO alone are typically not enough to make order distinct; so I have to<br>
include other objects, but there is no direct way I am aware of to implement<br>
multi-property sorting except for (complex) code-based tree-navigation<br>
within the compare function<br>
- if both assumptions 1. and 2. are correct, it seems my only chance to<br>
implement this is a strictly serial rule sequence / NO parallel branches<br>
(results in really ugly rule implementation for me) - <br>
I know those are hard to answer in general but:<br>
- are there any additional sources of indeterminism which I did not<br>
realize..?<br>
- better idea to tackle this for an existing (non-trivial) transform?<br>
<br>
Thanks<br>
Simon<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
great-users mailing list<br>
<a href="mailto:great-users@list.isis.vanderbilt.edu" target="_blank">great-users@list.isis.vanderbilt.edu</a><br>
<a href="http://list.isis.vanderbilt.edu/cgi-bin/mailman/listinfo/great-users" rel="noreferrer" target="_blank">http://list.isis.vanderbilt.edu/cgi-bin/mailman/listinfo/great-users</a><br>
</blockquote></div>