-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Problem in Crossover? #12
Comments
Actually, never mind - setVariable in TransformationSolution already marks the solution as dirty... weird. For some reason there are instances where I get targets for |
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. |
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 :-) |
Just a shot in the dark, since I don't know any internals of MOMoT and your description is rather specific: |
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
The text was updated successfully, but these errors were encountered: