I created a simple Geant4 code that generates a NIST.xml materials file, that contains all isotopes, elements and materials as they are defined in Geant4 NIST database. This code should only be run once and the file is already committed in the repository (itās there in case anyone wants to add additional features or check it out). It was produced using version v10.7.1 of Geant4 (but there shouldnāt be any change between versions).
There is also a generate_materials.py script that merges the .xml files defined in the script into a single file, while checking for no duplicate materials (or elements, isotopesā¦) and also checks that the ārefā used to build all materials has been previously declared.The file generated right now is named materials.nofinal.xml to maintain compatibility, but I believe the final materials.xml should be built this way.
All user defined materials should be inserted into dedicated .xml files (such as gases.xml that I already created) that use as references the elements/materials defined in the NIST.xml file whenever possible.
Once all required materials are moved into these format, we will be able to use this generated file as materials.xml . Mind that even though we could, for example, define a material named Steel using NIST components, there is already a G4_STAINLESS_STEEL material defined, that will probably be identical. When defining geometries we should use these materials whenever possible, to avoid introducing errors.
Hi Luis, and thanks! thats very good step forward!
I believe having gases.xml at a separate file it is a very good idea, so that we encapsulate the required targetGasDensity and other variables encoded at the gas mixtures.
Now I wonder, as it was working before, the version header of the materials file was being read by TRestGDMLParser and passed to TRestGeant4Metadata to keep track the version of the materials used in our simulations.
Now that I imagine we could add one or more material entitites, i.e. materials.xml and gases.xml what will be the versioning approach?
On every push to master the clone on sultan is updated.
After update, the generate_materials.py script should be ran automatically. If no errors are detected on the materials, a new materials.xml will be generated (otherwise, no file will be generated).
The materials.xml file should be automatically synchronized with the file served at the http endpoint.
Regarding versioning, I agree that using the commit hash is a good strategy. I will implement this into the python script to tag the final materials.xml. I can think of a better way to do this versioning, using the script to pull the latest git tag + commit from the .git folder and generating an incremental human readable version number from it (also using all previous commits hashes for this), but just storing the commit hash as versioning will work for now.
I will do some modifications today and it should be ready to use. I would wait until that moment to resume synchronization.
Ok, great, probably some updates are needed also at TRestGDMLParser?
Does this need to be run automatically, I mean there could be some instructions at README.md on how to update the materials.xml file using generate_materials.py then push to the repository.
I agree that when we push a new materials file we should run a pipeline validation. Yesterday, we were able to reproduce the problem just with TGeoManager. So perhaps a simple geometry loaded with GeoManager using the new materials.xml file would be enough as validation.
Well, trusting on people to follow the readme can be risky. I donāt think that updating it automatically is complicated, I will look into it. Something that could be done in the pipiline is to 1. check that the materials.xml is OK 2. check that the materials.xml in the repository is equal to the one generated by the script.
I have implemented a versioning scheme. There is a āversionā file in the repository (with format 0.0.1) that tracks the version. On each execution of the script, the version is increased (the minor 0.0.1->0.0.2, to increase other just do it manually then run script). This version is also inserted into the XML header version tag.
Ok, but as discussed somewhere else, if we use different XML material files from the repository at a single geometry, which version will be registered at TRestGeant4Metadata?
You canāt use different materials files with different versions (or you shouldnāt). You should only point to the single materials.xml that is uniquely identified by the version number (0.0.1ā¦) or its commit hash. The version registered in TRestGeant4Metadata will be the human readable version number of the file or its commit hash (or both).
Ok, but thats a restriction. I thought it would be interesting to have gases.xml where we define gas mixtures with variables such as density, pressure, ā¦ and other materials.xml file with standard materials. If I use both files in my geometry description, both will have the same version number?
Then, if you get the commit_hash from the repository. https://sultan.unizar.es/materials/.git/FETCH_HEAD. This serves to tag all the material files. Why we should be constrained to use a unique materials file?