I find that when processing my files several times the existing variables in the analysisTree get a new prefix named old_. I.e. when processing once I would get old_sAna, when processing twice I would get old_old_sAna, etc.
It would be highly desirable that the name of this analysisTree variable would be preserve at any stage of the processing.
I don’t see the reason why this should be like that. In any case, we should add protection to avoid instantiating another analysis process with the same name.
I.e. if sAna already exists, we should produce a warning and auto generate sAna2.
It is annoying that the name of my variables change as a function of the number of times that I have processed, or called restManager.
Sometimes we need to inherit the old observables from input file to output file. In order to mark them, I append the prefix in their names. I didn’t consider the case that you run one same process repeatedly.
Indeed, this logic needs to be discussed further. But I don’t think changing “sAna” to “sAna2” solves the problem. “sAna2” could also be a process name…
In my use case that would always be the case. The analysis tree was born to keep track of all observables generated along the processing chain. I will always want to keep track of those observables. And I want them to keep the same original name I gave in previous processing executions.
It is not like they can be replaced, or substituted by new values, the observables/variables in the analysisTree are the results of the event at a given stage of the analysis, and their name, sAna_ for example, is connected with the name of the process that was generating them. We just should not allow 2 processes with the same name.
Or in other words. If I launch 6 processes in 1 RML, or 3+3 processes in 2 RMLs, being the same processes with the same parameters. The final analysisTree in each of both processing schemes should be exactly the same.