clarify management of gemoc-gen folder

[dvojtise]

currently when running multiple simulations, the engine creates one folder per execution in the gemoc-gen folder.

most of the time this only contains a copy of the executed model without any additional interesting data. In the past these folders were used to also store some trace model

we should either:

• avoid its creation when not required
• or automatically clean it (especially when these folders don't contain any valuable data)
• or make sure to always overite the same folder (with the question of the possible simultaneous run of the same model with possibly different arguments ?)

Note: the exact behaviour may be different between engines which may create additional files there

[ebousse]

I would be in favour to only create this folder when some addon is recording data, eg. recording a trace.

[dvojtise]

I think we also have the generation of intermediate files in the case of the concurrent engine (mse model ?)
we should distinguish the recording (ie. something like a backup) from the generation of execution support files. (and make sure that 2 simultaneous executions can work ?)

[Faezeh-Kh]

Hi, I also wanted to report an issue with this gemoc-gen folder.
Considering a model as an xtext resource that after its execution, it is just copied in the gemoc-gen folder.
In this case, the original model and the executed one in the gemoc-gen folder are the same resources.
Therefore, for each object of the model, we get an error saying that the same object is defined twice (or more when executing the model several times).
For instance, I am using minijava DSL from here which is a subset of java as an interpreted DSL.
In the attached screenshot, you can see a sample minijava model and the errors after model execution.
I suppose we need to be able to disable gemoc-gen creation when it is not required.

[dvojtise]

@Faezeh-Kh
Being the same resource is actually normal since the copy is intended to be used by the trace file
Ie. the trace model is supposed to get its references to the copy of the model and not in the original one that can be modified later. (cf. #206)

However, you're right:

1. there should not be any copy if no trace model is saved
2. copying an xtext can generate issue since xtext often uses a project scope (leading to duplicate/conflicting objects).
3. The copy is probably incomplete in many situations, since it copies only the main resource and not its possible cross references. (multiple xtext file, but also probably in the case of model split into several "xmi" files)

For these second and third points, we may consider the following fixes:

• systematically save the model as xmi instead of xtext,
• and make sure to gather all resources (resolveAll of the resourceSet) that are in the current project into a single xmi file (maybe not optimal if some behavior relies on the resource containment information but should be ok in most cases 🤔 )

[Faezeh-Kh]

Hi,
In our last discussion, you mentioned one of the use cases of copied models under gemoc-gen is to be used by the trace file. However, as I am checking the latest version, it seems the trace model refers to the original model not its copy.

[dvojtise]

You're right, we probably need to fix this too, otherwise this model copy is pointless
The running model is using its own copy in memory, so for me, the only purpose of such a model on disk is to be a reproducible base for the trace model ...