| Summary: | Can't retrieve postition information from volumes defined in GDML modules! | ||
|---|---|---|---|
| Product: | Geant4 | Reporter: | b.riese |
| Component: | persistency/gdml | Assignee: | Gabriele Cosmo <Gabriele.Cosmo> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | normal | CC: | b.riese |
| Priority: | P3 | ||
| Version: | 9.2 | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Attachments: |
VolAuxInfo.hh
VolAuxInfo.cc setup.jpg E01MU1.gdml DetectorConstruction.hh DetectorConstruction.cc |
||
|
Description
b.riese
2009-11-09 13:53:34 CET
The transformation printed from a pointer to the physical-volume refers to the coordinates -local- to the mother volume, which in this case for 'd04_tube_vol' seems not to be the 'world', as for the other elements. In order to retrieve the position in -global- coordinates system (i.e. reference system of the world) you need to apply all transformations in opposite order through the hierarchy of volumes (see also section 4.1.8.2 of the Users Guide for Application Developers). This may not be sufficient and not always possible though, in case of multiple copies of the same hierarchy, replicas or parametrised volumes... For your use-case, it is preferable to extract the information a-priori (eventually from the GDML structure implemented) and use it in your application. An additional problem related to the use of GDML modules appears during the reading of matrices that are defined in the define section.
G4double val = parser.GetMatrix("m").Get(1, 1);
doesn't work if I define ion optical matrices in GDML modules (= beamline elements). Preliminary I'll define my 6x6 matrices in a seperate xml-file using
<!ENTITY matrix SYSTEM "matrix.xml">
command.
Thanks for your help,
Björn Riese.
If you can provide us a simple toy-example which reproduces the problem claimed, it would be much easy for us to verify. We don't see any of the issues reported here as a problem related to the usage of modules in GDML, sorry! Created attachment 55 [details]
VolAuxInfo.hh
In my GDML-Files I use the following Auxiliary Tags ...
<auxiliary auxtype="Dipole" auxvalue="RADIUS"/>
<auxiliary auxtype="IonOptics" auxvalue="ON"/>
<auxiliary auxtype="Quadrupole" auxvalue="GRADIENT"/>
<auxiliary auxtype="Color" auxvalue="YELLOW"/>
<auxiliary auxtype="SensDet" auxvalue="ON"/>
... and save them (see code 1090) in a linked list consisting of ...
struct VolAuxInfoData {
G4String MotherLogVol;
G4String PhysVol;
G4String LogVol;
G4String AuxType;
G4double AuxValue;
G4GDMLMatrix Matrix;
G4ThreeVector Translation;
VolAuxInfoData* Next;
};
... struct elements and belonging to the class "VolAuxInfo.cc/hh". "DetectorConstruction.cc" calls the following methods:
AuxInfo->AddVolAuxInfoData(pv_name, mv_name, lv_name, type, value, Matrix, translation);
AuxInfo->PrintVolAuxInfoData();
AuxInfo->SetVolAuxInfoQuadrupole();
AuxInfo->SetVolAuxInfoSextupole();
AuxInfo->SetVolAuxInfoColor();
AuxInfo->SetVolAuxInfoSensDet();
The geometry description consists of one main gdml file with drifts and modules. I use modules for detectors, dipoles, quadrupoles and sextupoles (see "setup.jpg").
I've also attached the classes "DetectorConstruction.cc/hh" and "VolAuxInfo.cc/hh" of the code and a gdml module of the dipole "E01MU1.gdml".
Created attachment 56 [details]
VolAuxInfo.cc
Created attachment 57 [details]
setup.jpg
Created attachment 58 [details]
E01MU1.gdml
Created attachment 59 [details]
DetectorConstruction.hh
Created attachment 60 [details]
DetectorConstruction.cc
|