search

martin-fleck / momot

Marrying Search-based Optimization and Model Transformation Technology
http://martin-fleck.github.io/momot/
17 stars 6 forks source link

Problem in Crossover? #12

Open sjiherzig opened 7 years ago

sjiherzig commented 7 years ago

Hi,

I ran into a weird problem today which, I think, is a result of re-using the crossover operators of MOEA directly. Specifically, I kept getting "XYZ is not contained in a resource" type errors on occasion at the end, when the framework was trying to save the models.

It seems that, during crossovers, references to elements in other solutions can be preserved (with a resolvable proxy to another solution). For instance, say you have simple problem with two classes A and B, where A has a reference property to 0..* Bs called "b" (containment). Your initial solution contains only an instance of A. Let's say a rule is to add a B to an A. That means, your Henshin rule would have a (preserve)A, and a (create)B, with a (create)b from A to B. When crossing over two solutions S1 and S2, the solutions are NOT marked as dirty, meaning that S1 and S2 suddenly contain cross-references (since the As in the matches are still bound to the original graph).

Weirdly, this doesn't seem to always happen. The mutation operators mark the solution as dirty, thereby forcing re-evaluation of the matches. However, I don't see the equivalent on the crossover operator. Not sure whether dirtying the entire solution would be a good idea - perhaps just part of the solution needs to be re-evaluated?

Let me know your thoughts...

Sebastian

sjiherzig commented 7 years ago

Actually, never mind - setVariable in TransformationSolution already marks the solution as dirty... weird. For some reason there are instances where I get targets for Matches that are non-null, and refer to elements of a different solution... strange.

martin-fleck-at commented 7 years ago

I am not sure if there is an actual problem now or not? What you are describing should not be happening and sounds a bit worrysome: matches referring to elements of different solution models.

sjiherzig commented 7 years ago

Good question - it happens sporadically on some models. E.g., in one case, weirdly, consistently if I change the multiplicity in that case from 0.. to 2.. - the solution produced seemingly ensures two elements being added, but the second element consistently refers to a different source graph in the "partial match" of the henshin match.

I wonder if this is a Henshin bug. I can try and create an example at some point, but I suspect you probably don't have much time to look into this :-)

Leative commented 6 years ago

Just a shot in the dark, since I don't know any internals of MOMoT and your description is rather specific: Don't reuse Henshin-UnitApplications in sequences of rule executions if you use IN parameters. I've encountered problems where already assigned parameters of a former rule execution have been reused in a later rule execution. I could imagine this may lead to strange cross-references in certain situations.