I am trying to create simple life game agent model. Attached is an initial model I created (no actions). I see that EMF validation succeed, but when the project builds on model save, it create the java file with compilation error. I tried to repeat the steps from tutorial screen cast. In any case, I think if the model validates it should produce only valid artifacts.

I am trying to create simple life game agent model. Attached is an initial model I created (no actions). I see that EMF validation succeed, but when the project builds on model save, it create the java file with compilation error.

That's a cool thing to try. I've fixed the problem that you had. You tried to specify the same agent as both the fill agent and a member of "agents", i.e. the contained agent. I simply removed the agent and it compiled fine. I even added in a state and visualization bits.

Quote:

I tried to repeat the steps from tutorial screen cast. In any case, I think if the model validates it should produce only valid artifacts.

In an ideal world, your're right. It is actually quite easy to add new checks like this, so you might want to file a bug report. But there are a number of issues that come into play here.

We need to distinguish between syntactic and semantic validation. Although in this case you end up with a Java artifact that is obviously wrong, viewed from the point of view of the model validation process this is still closer to the case where someone creates a Java program that will compile, but that will produce an error when it is run.

Also, there is the issue where somethings might be reasonable in one target but not in another. For example, you might want to target an API that can only handle 2D spaces but not GIS. Then the model will be invalid for one target but not another.

In this case, I think that we could put in a check for wether the fill agent and agents are not the same, though I'm thinking that it should probably be a warning rather than an error as I'm not quite sure that there isn't a case where this kind of usage would be appropriate.

Incidentally, there is an interesting issue here WRT synchronous updating. With a typical ABM engine you are not going to be able to reproduce Conway's results. This is because Conway's life is a classic CA. In CAs, state transitions are applied to all cells in parallel. IOTW, for a given iteration cells do not take into account any changes that occur within other cells in that same period. In contrast in a typical ABM model cells are updated in a (pseudo) random order that is sequentially.

You can achieve get the same effect by storing the result from the previous calculation into a temporary value and then copying that over to the actual value in another rule.

I suspected that the validation of the model is merely syntactic EMF validation. And more deeper semantic validation is needed.

From the other hand, I just started to investigate AMP and I don't know the semantics yet. I picked Cellular Automata Life game to learn programming ABM models. I thought that this might not as simple as it looks.

I suspected that the validation of the model is merely syntactic EMF validation. And more deeper semantic validation is needed.

Yes, but to be clear we do have all of the infrastructure in place for this and a reasonably decent set. As you can see from the file below, they are super easy to define, so if you or anyone else have ideas for improvement, please do submit a bug or better patch for it..

From the other hand, I just started to investigate AMP and I don't know the semantics yet. I picked Cellular Automata Life game to learn programming ABM models. I thought that this might not as simple as it looks.

Yes, sometimes the simplest things are the hardest. Ironically, this is one programming exercise that is trivial for parallel programming but harder for serial.
It is very often the case with ABMs that model features end up being artifacts of the way that rule execution and space is designed.

One of the major -- if not the major -- point of AMF is to allow the user to test and experiment with models under these different conditions by only changing one value in the model. This very use case is one of the things that drove me to take a model-driven approach. So we will support this transparently in the future..

In order to support parallel updating OOTB, we will only need to add a "parallel update" rule or attribute to meta-model and then we could extend the code generator to handle all of the mechanics of this!