I have started to investigate what would be the optimal approach for me to store a relatively complex detector model. My impression is that the GDML approach is probably the most suitable one, but I am not sure. It seems to me that other people have trouble getting started as well:
I think that a guide comparing all available approaches would be useful, and I was thinking that I could document my learning process for others. Unless this has been done already, of course, in which case I would love to read it But if not, it would be great if someone experienced could guide me a bit through this.
Implementing UI commands that create the model parametrically.
Using another file format (in practice, reimplementing points 2/3 with a reduced set of features).
Did I miss anything?
Of this, GDML seems to be the winning choice for me. But there are many things I’m not sure. Is the ASCII format deprecated-ish in favour of GDML? What makes it preferrable otherwise? Etc.
Thanks for the excellent summary. When you say GDML is winning, have you compared importing a CAD geometry by converting it to GDML with importing it directly using CADMesh?
I am curious how it is in terms of load time, memory and even runtime as I have ran into problems with very “fine” meshes in .stl or .ply giving trouble to the G4 geometry navigator.
I have not compared anything yet! So far I have only managed to collect the alternatives, look a bit at what the formats look like, etc. It is looking like it’s winning for us because it seems to have better support than ASCII, and because we don’t need complex surfaces but would rather rely on Geant4 solids like G4Cons, G4Box, etc. rather than triangular meshes.
Performance was not something that I was concerned in my analysis, but indeed a decent review should evaluate that!
I doubt that the runtime performance issue is related to the way the stl file is imported into a G4TesselatedSolid.
With CADMesh, you could also try to make use of the the “tetgen” option to create tetrahedals instead of a mesh, this could allow the navigator to improve voxelization?
Would anyone have any piece of advice to give to me about what to pick, and why? Like “I do not recommend approach X because of Y”, and “Tool A has this feature but tool B will let you do that thing”.
I am now delving into GDML documentation, I have one practical question: does GDML support reading only some geometric elements from the GDML file, or does it need to contain the whole description, to which nothing can be added later? Ie I would like to have different parts of the system in different files, and possibly the world volume hard-coded in the source. Would that be possible?
OK, I am suspecting that G4GDMLParser::ReadModule() and G4GDMLParser::GetVolume() are exactly what I need, but they are not mentioned in the GDML guide. I guess they are not documented?
Thank you Gabriele! I noticed that the guide contained the description of the format, but not how use modules from Geant4. This is what I was referring to.
I think that I can hack my way through… But in all honesty, and I hope nobody reading this gets offended, I was not a big fan on the interface for selecting the correct thermal cross sections, and in my opinion this reveals the issues. I mean, if (big if) thermal scattering were to be supported in GDML, it should look completely different.
Hi Sergio,
GDML is only related to geometry detector description, and nothing else.
Please, if you find anything missing or to improve related to documentation, submit a Bugzilla ticket rather than posting on the Forum on topics totally unrelated. Thanks,
Gabriele
GDML is a persistency format and Geant4 simply can import and export such format. Is there any particular reason why you need to know the implementation details of how Geant4 achieves that?
My apologies if I am adding unnecessary noise over here. I am not quite sure about where to move the discussion to; or if I should split it. In other forums I have participated in it is expected that discussions derail a little bit, especially since there is not so much volume of messages in this thread.
I leave here some responses; no need to address them here but it is easier than writing them in my local machine and risking losing them.
One the things that I am trying to do is precisely understand better if things are bugs or features before I report the issues, this is why I thought it was a good idea to write here instead of directly reporting a bug… On the other hand, I have been contacting already @witoldp to provide some feedback, which to my understanding was relevant. Actually I am currently reading the guide from beginning to end to really understand the available features, and will share with him some more comments.
About the thermal scattering, that is exactly the issue: the framework used for thermal physics requires a special definition of the materials, since not only elements, but also their chemical environment, need to be specified. I.e., this is part of the detector definition.
And about modules, I did not think I was asking about implementation details. I will study better how modules work and I will post later if I still have questions…
OK, this is good. Feedback is always welcome, but please, directly interact with the responsible if you can!
Chemical environment is not considered to be described in GDML…
You are right in Geant4 we do not directly explicitly provide documentation about the handling of GDML in the manuals… Geant4 interprets the GDML schema in most if not all of its aspects, entities get automatically loaded in Geant4 as long the GDML schema is implemented in the GDML file, such that in general it is not necessary to know beyond what G4GDMLParser provides. Example G01, for instance, demonstrate several features of the parser, including how to import separate entities defined in different files… Although trivial, we could add an example demonstrating the importing of modules as well.
Thank you very much, Gabriele once again!!! That was a wealth of information!
Yeah, about the chemical information, I have to see how I have to go about that, because the problem is that thermal scattering is fundamentally incompatible with GDML. I think that I can get away with it by creating the detector, and then replacing the relevant elements in each material with the corresponding TS-enable version of the element. Sigh. But I’ll fight that battle and come begging for help when I know more, now this is just ranting here
I am providing information for MRADSIM Converter. You can easily convert the geometry designed in 3D from any CAD program (Solidworks, Fusion 360) to GDML format via MRADSIM Converter. You only need to output the STEP format of the 3D file. For now it only creates points and triangles in mesh format. In addition, you can define materials for geometries.
MRADSIM Space, all GDML models are supported. These can be Geant4 Solids or mesh models. There is software that you can use to simulate directly. You can perform complex simulations by clicking next, next, run buttons without installing Geant4
support for geant4 solids would be truely phenomenal
many parts with holes could be modeled as boolean solids, subtracting the cylinders from the tesselated object. would this improve performance? round holes usually increase the triangle count so significantly…
But if not, it would be great if someone experienced could guide me a bit through this.
So far I have only managed to collect the alternatives, look a bit at what the formats look like, etc. It is looking like it’s winning for us because it seems to have better support than ASCII, and because we don’t need complex surfaces but would rather rely on Geant4 solids like G4Cons, G4Box, etc. rather than triangular meshes.