Move project folder structure to a more comprehensive way

[juanangp]

While I was creating AlphaCAMM project I found that the projects in the repository https://github.com/rest-for-physics/framework/tree/master/projects are split in different subfolders (projects) that doesn't follow a comprehensive structure, e.g. for IAXO we have: iaxo-analysis iaxo-simulations iaxo-geometry iaxo-readouts

I would suggest to create a folder (project) named iaxo and create inside the different sub-folders: analysis, simulations, geometry and readouts. I am working in a project for alphaCAMM that we can use as template or at least we can iterate over it.

[jgalan]

It could be easily moved to a new iaxo folder. Still I would like to keep iaxo-simulations or trexdm-simulations since that makes reference to the remote repository name.

[jgalan]

It would also be interesting to adopt a dedicated repository scheme for each topic, geometries, readouts, simulations, analysis, etc.

Thats why the basic-geometries or basic-readouts, basic-simulations ... basic-analysis. It creates a model or pattern on how to organise the project that will benefit from anyone using the same model.

Perhaps, the basic-xyz projects could be used as template.

Following that scheme one could have alphacamm-simulations, alphacamm-analysis, etc.

If we try to keep similar project structure, that would help I believe. We can always create a macro project joining those sub-projects as a submodule and create a release.

I believe it is good we share a project model for creating the project structure in a similar way. Keeping a similar structure will help others to jump between projects more easily, I think.

[juanangp]

I have created different projects which are implemented as submodules in https://lfna.unizar.es/gifna/alphacamm/ that I think should be placed as a submodule under projects

I would suggest to move the different projects to the same structure, also I would suggest to move basic-xyz to template-xyz if are meant to be used as a template.

[jgalan]

For the basic-xyz I wrote them more thinking on them as basic examples, but they follow the project structure model. That we could of course revisit/update/discuss.

The template idea was implemented to be used at https://github.com/iaxo. --> detector-analysis, detector-geometry. Still this might require polishing.

I don't think it is necessary to write "template" directly at the repository name, since it is visible that it is a template at the GitHub view, and detector- is a generic enough keyword to name a template project.

I let @lobis decide about detector-geometry becoming a template.

Then, perhaps it would make sense to create a new project detector-template (or detector-project) that implements detector-readout, detector-simulations ... as a submodule. And then, it makes sense to transfer these projects inside rest-for-physics organization, and add detector-project as a submodule inside /projects/.

[jgalan]

So, for example, if we develop simulations for IAXO-D0 detector we would get iaxod0-simulations that was created using the detector-simulations template.

[jgalan]

I am open to place those detector-xyz templates in another repository or organisation. But at the time it made sense to put it inside IAXO.

[lobis]

I let @lobis decide about detector-geometry becoming a template.

I would say no for the time being, its not very useful as a template at the moment since its too specific and people can still fork it and so on if they really want.

but it would be nice to have a geometry template repository to produce complex geometries, but I am not sure if the kotlin gdml.kt is the right tool since even though its really nice very little people know kotlin.

[jgalan]

I have created a detector-project to serve as a reference project.

https://github.com/rest-for-physics/detector-project

Once there is some feedback and this project gets discussed, we may start to move iaxo and trexdm into standalone projects following the similar structure.

[juanangp]

I have some comments on https://github.com/rest-for-physics/detector-project which I really don't know where to place, so I put them here:

• detector-geometry: move folder root to macros
• detector-analysis : Move globals.xml, run.xml and perhaps processes.rml to a new folder common.
• detector-simulations: Under studies, I don't think it is a good practice to use shell scripts to launch simulations, neither to export global variables, these variables should be local within the simulations. I would suggest to move these variables to globals.xml or it can be changed in the rml file directly, which can be done by the user. Also I would suggest to move away from this scheme of launching simulations. However, I an not against using python scripts to launch the simulations since the variables are defined locally.
• detector-simulations: move folder scripts to macros

[jgalan]

Personally, I find writing shell scripts handy, and using system variables allows to use RML as templates. Of course, the <globals> <variable ...> section will allow to define the variable in case the system variable is not defined.

This way I am able to define a full bunch of simulations to be sent to a batch system. For example, I could have a bash shell script that launches 300 simulations as follows:

export RUN_NUMBER=100
export REST_ISOTOPE="U238"
restG4ToCondor.py --c internalContamination.rml --r 100

export RUN_NUMBER=200
export REST_ISOTOPE="Th232"
restG4ToCondor.py --c internalContamination.rml --r 100

export RUN_NUMBER=300
restG4ToCondor.py --c cosmics.rml --r 100

[juanangp]

In this particular case I think would be better to parse these variables to the python program and then you handle inside. Note that using this approach you should redefine these variables every time you launch the program. I found a very bad example in the simulations that were implemeted for AlphaCAMM in which the simulations were launched using a shell scripts where most of the variables were exported as system variables.

[jgalan]

In the case above the variables are defined inside the script and are used for the execution of the command just afterwards. Perhaps there are other user cases which do not make a good use of it, but I see no a big problem on the above approach.

Anyhow, we could avoid using system variables if we implement something like the feature proposed at rest-for-physics/restG4#32 where the variables given in the command line could redefine any parameter inside the configuration file.

We could even use system variables at the command line if the user wants to do so:

restG4 --run:user=$USER --g4metadata:Nevents=$NEVENTS

[jgalan]

Note that using this approach you should redefine these variables every time you launch the program.

Not really, if it is defined at <globals> it might be redefined using the system variable. There is an overwrite option inside globals.

<globals>
         <variable name="RUN_NUMBER" value="auto" overwrite="true" />
</globals>

overwrite=true will avoid that the system variable is transferred to the RML, and it will always be auto.

https://sultan.unizar.es/rest/classTRestMetadata.html