[great-users] Order properties/guarantees in GreAt transformations

[Kevin Smyth]

Hi Simon,

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.

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.

Kevin



On Fri, Dec 7, 2018 at 4:35 AM Simon Görke <
simon.goerke at ils.uni-stuttgart.de> wrote:

> Hello everybody,
>
>
> I have a Great transformation which needs to set an attribute to a unique
> (integer) ID.
> My key requirement is that, for a given atom/model, the ID is assigned
> identical if
> a. two successive transformation runs are performed on the same input model
> (same rule.exe).
> b. the rule is not changed structurally in the graphic modelling, but it is
> recompiled (e.g. because some unrelated attribute setting needs fixing)
>
> What I did is using a global variable which is initialized once to "0" and
> increment it after each assignment to the ID attribute.
> Unfortunately this assignment is distributed over several rules like so
> (hope ascii graph survives mail formatting):
>
>
> /-------------------rule2_matchY_createX ---> setID_of_X
> rule1_Init_globalvar_to_0 ----<
>
> \-------------------rule3_matchZ_createX ---> setID_of_X
>
> I.e. rule2 and rule3 are parallel rules which contain different matching
> patterns but result in newly created atoms of same type "X".
> (This is a simplified example - actually my rules are already existing and
> I
> have to add this ID property to them retroactively / rule which create X
> are
> widely spread in the transformation...)
>
> Obviously, this approach was too naïve wrt the requirement above, i.e. IDs
> are NOT ALWAYS assigned deterministically between two successive runs.
> I guess there are (at least) two problems with this:
> 1. matching in rule2 is not deterministic wrt the output sequence of X-type
> atoms. Same for matching in rule3.
> 2. call order of rule2 and rule3 is not deterministic after recompilation
> (due to Great c++ code generation being not deterministic). Not sure about
> this - maybe great generates the functions top rule first or something?
> Then, this would be a non-issue.
>
> So:
> - if only 1. Is correct and 2. NOT, I could merge (serialize) the outputs
> of
> rule2 and rule3 into one rule and try to find a unique property which can
> be
> used for sorting before actually assigning the ID.
> Problem here: only one output port can be sorted and the attributes of this
> FCO alone are typically not enough to make order distinct; so I have to
> include other objects, but there is no direct way I am aware of to
> implement
> multi-property sorting except for (complex) code-based tree-navigation
> within the compare function
> - if both assumptions 1. and 2. are correct, it seems my only chance to
> implement this is a strictly serial rule sequence / NO parallel branches
> (results in really ugly rule implementation for me) -
> I know those are hard to answer in general but:
> - are there any additional sources of indeterminism which I did not
> realize..?
> - better idea to tackle this for an existing (non-trivial) transform?
>
> Thanks
> Simon
>
>
>
>
>
>
>
>
>
> _______________________________________________
> great-users mailing list
> great-users at list.isis.vanderbilt.edu
> http://list.isis.vanderbilt.edu/cgi-bin/mailman/listinfo/great-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.isis.vanderbilt.edu/pipermail/great-users/attachments/20181207/8f301d0a/attachment.html>