Allow the creation of a(n almost) full geometry w/o a prior VMC instance#1113
Conversation
…nstance. This is done by inverting the current responsabilities. TGeo is now the master in charge of creating the geometry, and VMC is just the client taking the geometry from TGeo (and possibly tweaking media properties which cannot be handled by TGeo itself).
|
Error while checking build/O2/o2-dev-fairroot for a4d7427: Full log here. |
|
Nice PR. I will check if the simulation still runs exactly as before by cross-checking the number of steps done in each module (using the StepLogger). If all goes fine, this will go in. |
|
I am afraid that the first QA check did not pass. I ran the following command on dev and here: This is using a random selection of modules. I see a totally different number of steps done and much less secondaries for this new PR. |
sawenzel
left a comment
There was a problem hiding this comment.
We have to block this until we can show that it doesn't affect simulation.
|
ok. will get back to the drawing board then ... |
|
Can we maybe close this PR and reopen later? The CI servers will be happy. |
shahor02
left a comment
There was a problem hiding this comment.
Hi @aphecetche
At least for the FIT this hits the problem I've mentioned before in the alice-talk: the optical properties are set in the ConstructGeometry directly on VMC media, which means that the VMC must already contain these materials. Your trick with run->SetImportTGeoToVMC(true); in o2sim will not help here, since the FairMCApplication calls
if (fRun->IsImportTGeoToVMC() ) {
TVirtualMC::GetMC()->SetRootGeometry(); // notify VMC about Root geometry
LOG(info) << "TGeometry will be imported to VMC" << "\n";
}
after the loop over the ConstructGeometry for every module.
|
Hi @shahor02 Indeed that must be the issue, and there's a massive difference because of the TPC SetSpecialPhysicsCuts call... (e.g. just using ITS or commenting out the SetSpecialPhysicsCuts calls, I get the same hit counts) Have to think a bit ... |
|
@aphecetche : I think, also detectors which ConstructGeometry directly via Cheers, |
|
Well for the moment you could just use in the MaterialManager (like in Detector): This should leave the simulation intact and allowing you to test geometry standalone. |
The other way around does not yield the same simulation results, and this is not understand for the moment. Until it is, VMC is kept as the driver, while TGeo can be used standalone to e.g. test to geometry.
|
Error while checking build/O2/o2-dev-fairroot for 543a6b6: Full log here. |
|
indeed, after a bunch of inconclusive tests (meaning I still don't understand why I don't get the expected same results with TGeo driving the geometry creation), I added a couple of if in MaterialManager for the moment, to get the thing moving forward. Created a JIRA ticket for future work. |
| #include "DetectorsBase/MaterialManager.h" | ||
| #include <TVirtualMC.h> // for TVirtualMC, gMC | ||
| #include "TString.h" // for TString | ||
| #include "TVirtualMC.h" |
There was a problem hiding this comment.
why these changes? They are not necessary for this PR, I guess.
There was a problem hiding this comment.
hum, no, indeed. In the original commit that include was no longer needed, then I put it back in the second commit but as a quotes include instead of angled include, out of habit I guess (as I've never quite understood why is Root considered a system include ;-) )
|
I squashed the 2 commits since it is not interesting to have the intermediate (breaking) state. |
…nce (AliceO2Group#1113) * Allow the creation of a(n almost) full geometry without a prior VMC instance. Whenever a VMC instance is not present, allow to use direct TGeo constructs for material/medium construction. This allows to perform standalone tests without having to instantiate simulation.
Decoupling TGeo material creation from VMC (i.e. can now build TGeo material without having to instantiate first a TGeant3TGeo or TGeant4 object)
This is done by inverting the current responsabilities. TGeo is now the master in charge of
creating the geometry, and VMC is just the client taking the geometry
from TGeo (and possibly tweaking media properties which cannot be
handled by TGeo itself).
The net advantage is to get a lighter dependency tree and is useful e.g. to build a geometry within a unit test.