search

LDMX-Software / ldmx-sw

The Light Dark Matter eXperiment simulation and reconstruction framework.
https://ldmx-software.github.io
GNU General Public License v3.0
22 stars 20 forks source link

gdml to TGeo friendly gdml #574

Closed tomeichlersmith closed 4 years ago

tomeichlersmith commented 5 years ago

Currently, the ROOT implementation of gdml parsing struggles with the more complicated gdml parts (like loops and replica volumes). We can get around these struggles by having a utility translate the original gdml files into a ROOT-friendly gdml file.

I hope to use Geant itself to do this translation by importing the detector geometry into Geant and then exporting it back into one file (maybe with some specific write options).

tomeichlersmith commented 5 years ago

I have been able to write an executable in the DetDescr module, but ROOT is still unable to handle the magnet. ROOT doesn't know the triangular tag for some reason, but going through Geant4 does produce less errors when importing to ROOT than trying to input the gdml files directly (and drawing after importing can be done).

The error TGeoManager::Import throws is

Error: Unsupported GDML Tag Used :triangular. Please Check Geometry/Schema.
^^^ Copy of this error for each triangular in magnet.gdml ^^^
Solid: coil_10x1f792c0, Not Yet Defined!
Solid: coil_20x36fe060, Not Yet Defined!

It seems like ROOT can't define the coils because it doesn't know how to draw the triangular tessellation. I tried using the schema defined at the header of the detector.gdml file in the G4GDMLParser::Write command, but that didn't change the output. Looking in to if this is a ROOT incompatibility or if I can include a specific schema to tell ROOT how triangular works.

omar-moreno commented 5 years ago

Yeah, this is the same issue I was running into before. That's why I created the geometry without a magnet in it. Try using that one.

On Mon, Jul 15, 2019, 5:12 PM Tom Eichlersmith notifications@github.com wrote:

I have been able to write an executable in the DetDescr module, but ROOT is still unable to handle the magnet. ROOT doesn't know the triangular tag for some reason, but going through Geant4 does produce less errors when importing to ROOT than trying to input the gdml files directly (and drawing after importing can be done).

The error TGeoManager::Import throws is

Error: Unsupported GDML Tag Used :triangular. Please Check Geometry/Schema. ^^^ Copy of this error for each triangular in magnet.gdml ^^^ Solid: coil_10x1f792c0, Not Yet Defined! Solid: coil_20x36fe060, Not Yet Defined!

It seems like ROOT can't define the coils because it doesn't know how to draw the triangular tessellation. I tried using the schema defined at the header of the detector.gdml file in the G4GDMLParser::Write command, but that didn't change the output. Looking in to if this is a ROOT incompatibility or if I can include a specific schema to tell ROOT how triangular works.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/LDMX-Software/ldmx-sw/issues/574?email_source=notifications&email_token=AA4JMXD72B3P2RP67IL27SDP7TRZ7A5CNFSM4IDZSV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZ67O4A#issuecomment-511571824, or mute the thread https://github.com/notifications/unsubscribe-auth/AA4JMXAY2T2CZB3DTESZAFLP7TRZ7ANCNFSM4IDZSV2A .

tomeichlersmith commented 5 years ago

It works well without the magnet. After using the "translation" executable, I can draw the geometry in ROOT simply with

gSystem->Load("libGeom"); gSystem->Load("libGdml");
TGeoManager::Import("translated-file.gdml");
gGeoManager->Draw("ogl");

I feel like triangular is simple enough that ROOT would be able to handle it, so I'm going to try to figure out if there is a schema I can use that would help.

tomeichlersmith commented 5 years ago

As of April 2017, tesselated solids were not supported in ROOT (version <= 6.09/02). I have not been able to find any patches in the release notes for each version since then, so I think we are stuck.

tomeichlersmith commented 4 years ago

I am going to close this issue and fold it into the dd4hep implementation. Issue #584

omar-moreno commented 4 years ago

Have you started porting things over to DD4Hep? If not, we should reopen this issue. We need a TGeo friendly of our GDML for ACTS to work properly.

On Wed, Mar 25, 2020 at 8:35 AM Tom Eichlersmith notifications@github.com wrote:

Closed #574 https://github.com/LDMX-Software/ldmx-sw/issues/574.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/LDMX-Software/ldmx-sw/issues/574#event-3164518549, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA4JMXA63PB5AQ3GVA2GLFTRJIQCPANCNFSM4IDZSV2A .

tomeichlersmith commented 4 years ago

I was un-aware of the dependency on TGeo for ACTS.

What form of TGeo-friendly does ACTS need? In this branch, I have a small executable that "charms" gdml into one TGeo-friendly version. Should I port this code into another place?

omar-moreno commented 4 years ago

Basically, at the moment, we have a lot of the same constants defined in different files. If some of those constants is accidentally set such that it doesn't match the rest, then it causes issues when loading into TGeo. We saw this problem with the v9 geometry. The first goal was to pull out some of those constants into their own file so this doesn't happen.

Of course, we also need to remove tessellated solids. But the only component we have that uses tessellated solids is the magnet so that's easy enough to remove.

That said, if you had planned on porting our geometry to dd4hep in the next ~1-1.5 months, then I'm all up for closing this issue. I figured that wasn't going to be the case given that it might end up being a big job.

On Wed, Mar 25, 2020 at 8:41 AM Tom Eichlersmith notifications@github.com wrote:

I was un-aware of the dependency on TGeo for ACTS.

What form of TGeo-friendly does ACTS need? In this branch, I have a small executable that "charms" gdml into one TGeo-friendly version. Should I port this code into another place?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/LDMX-Software/ldmx-sw/issues/574#issuecomment-603913615, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA4JMXCFGK7XQNHV7XCHNB3RJIQ2BANCNFSM4IDZSV2A .

tomeichlersmith commented 4 years ago

It depends on how much I prioritize this. If I put dd4hep in front of everything else, I think I can get it done in about a month, but I've been working under the assumption that I should prioritize other bug fixes and improvements and delay the dd4hep transition to a later ldmx-sw version.

omar-moreno commented 4 years ago

That's fine, so let's delay the porting until other things are done and leave this issue open for now.

On Wed, Mar 25, 2020 at 8:53 AM Tom Eichlersmith notifications@github.com wrote:

It depends on how much I prioritize this. If I put dd4hep in front of everything else, I think I can get it done in about a month, but I've been working under the assumption that I should prioritize other bug fixes and improvements and delay the dd4hep transition to a later ldmx-sw version.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/LDMX-Software/ldmx-sw/issues/574#issuecomment-603920844, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA4JMXDSAQ6KL63MQBWNNDTRJISIDANCNFSM4IDZSV2A .

omar-moreno commented 4 years ago

Porting things to dd4hep will eliminate the need for this.