I’m a bit confused with the relationship between TGeo and VMC in O2 simulation code.
Are we supposed to be able to create a full geometry without having an actual VMC implementation (either Geant3 or Geant4) already chosen ? Because apparently we cannot…
Case in point : I’m trying to write a test for a MCH geometry transformer (local<->global coordinates). A simple implementation for such geometry transformer is just to retrieve the transformations from the relevant volume in the geometry.
But when the geometry is created, we use (like any other detector, I assume) the MaterialManager, which in turn uses internally … the VMC to create materials. If no VMC has been instantiated, that’s a recipe for a seg. viol (*)
Do we really need to create a full-blown transport engine to be able to play with materials ? Why can’t we just use TGeo consistently everywhere ?
(*) (actually the seg. viol is even before that when one tries to access the mag. field, for the same reason).
I think fully functional geometry cannot be created w/o VMC, since the TGeo has no methods to assign certain properties, e.g. TVirtualMC::GetMC()->SetCerenkov used by FIT.
Where exactly the segm.viol. happens due to the field?
Thanks for the answer. So indeed I got the wrong picture of the relationship : I thought VMC was fully using TGeo, but that’s not the case. I had a look at the code and indeed the material definition is driven by VMC and just “forwarded” to TGeo so the TGeo geometry written to disk has the material definitions (and so on reading a TGeo from disk one gets the materials).
But to create the material one indeed needs a VMC implementation defined.
Which makes my problem with the field mute as the issue was a deferencing of a VMC null pointer in `o2::Base::Detector::initFieldTrackingParams in case there’s no VMC implentation defined.
Now I understand that I can simply not do my test without a VMC implementation.
In most of the cases the materials/media can be fully created within the TGeo, then passed to VMC at the moment of its initialization. But some properties (particularly the optical properties) are missing in TGeo, so they are absent even in the imported/saved TGeometry version.
“In most of the cases the materials/media can be fully created within the TGeo, then passed to VMC at the moment of its initialization”
can be, but that’s not the way it is currently done in O2, is it ?
(as far as I can tell, most detectors use TVirtualMC::GetMC()-> methods for materials and medium, right ?)
Right, the MaterialManager currently creates the material and media directly in TVirtualMC::GetMC(), which makes it automatically to create the TGeometry equivalents also.
But then some detectors use TGeo getters to access media (like the ITS, which builds its geometry using TGeometry) and some do it via media ID’s stored in the MaterialManager since they create geometry using TVirtualMC::GetMC()->Gsvolu …).
OK, but assuming I have a detector which materials can be defined completely with TGeo (e.g. no optical properties to be set), can I actually decide to define everything with TGeo for my detector, and assume it will just work (e.g. the Geant3 and Geant4 implementations will always read in the TGeo information) or is it more subtle than that ?
If it’s not, then we could imagine to have the MaterialManager use TGeo whenever possible instead of VMC directly, right ? )
(the use case still being to be able to work simply from the TGeometry, without having to instantiate a full blown VMC-impl, e.g. for testing purposes)
I don’t think you can do this with current O2 implementation, since the MaterialManager 1st calls VMC material creator then maps it to TGeo. In principle, it could have been done in a way that 1st you create TGeo, then map it to VMC then set special properties. But it is not done it this way and doing it would require not only MaterialManager changes but also the MC initialization flow by the FairRoot, i.e. ConstructGeometry should both define the materials and build detector geometry for every detectors.
I guess it should in principle be possible to import externally defined geometries/materials.
(But given that executing with o2sim takes almost no time to setup at least a G3 instance … it is probably not a big deal to use the current setup?)
No, it’s not a big deal when using
o2sim but I was trying to make a unit test from my geometry, and as such wanted to minimise cruft.
Seems that with some relatively minimal changes in MaterialManager.cxx I am able to achieve what I want (decoupling the geometry creation from the existence of a VMC instance).
Before I propose a PR for your review(s), is there a “candle” test for simulation I could run to confirm I indeed did not break everything ?
Some sim tests are run as part of the unit-test collection. This should already be a reasonable check.
I currently have an issue with lib loading in one of them. I’m investigating…
❯ ctest -R sim
Test project /Users/laurent/alice/o2-dev/O2/build
Start 35: tpcsim_G4
1/4 Test #35: tpcsim_G4 ........................ Passed 17.37 sec
Start 36: tpcsim_G3
2/4 Test #36: tpcsim_G3 ........................ Passed 8.60 sec
Start 99: o2sim_G3
3/4 Test #99: o2sim_G3 ......................... Passed 10.84 sec
Start 100: checksimkinematics_G3
4/4 Test #100: checksimkinematics_G3 ............***Failed 1.53 sec
75% tests passed, 1 tests failed out of 4
Total Test time (real) = 38.44 sec
The following tests FAILED:
100 - checksimkinematics_G3 (Failed)
Errors while running CTest