restG4 output w/o geometry

[ybedfer]

System : Linux, MacOs, Windows? Linux
REST version : v2.2.10_dev

Hello again,
Same context as previous ticket restG4: no energy deposition. But energy deposit error now fixed.

New problems, while viewing restG4’s output w/ “REST_ViewG4Event”:

1. The geometry is not displayed in the TEve viewer.
2. restG4’s output file lacks a TGeoManager (may be the explanation for error (1) supra).
   Instead it has a TGeoElement:

root [1] .ls
TFile**         G4Data_ProtonsB_V1_00002.root
 TFile*         G4Data_ProtonsB_V1_00002.root
  OBJ: TRestAnalysisTree        AnalysisTree    AnalysisTree : 0 at: 0x88ccd00
  OBJ: TTree    EventTree       EventTree : 0 at: 0x88c7ef0
  KEY: TRestG4Metadata  protons_N1;1    ProtonsB
  KEY: TRestPhysicsLists        default;1       First physics list implementation.
  KEY: TRestG4Metadata  Historic_TRestG4Metadata;1      ProtonsB
  KEY: TRestPhysicsLists        Historic_TRestPhysicsLists;1    First physics list implementation.
  KEY: TRestAnalysisTree        AnalysisTree;1  AnalysisTree
  KEY: TRestRun CH-E;1  Simulations PRM v1
  KEY: TTree    EventTree;1     EventTree
  KEY: TGeoElement      Geometry;1      GERMANIUM

Note that I have no clue where the GERMANIUM above come from!!??
3) The execution of “REST_ViewG4Event” yields the following warning/error messages:

Error in <TBufferFile::ReadClassBuffer>: Could not find the StreamerInfo for version 2 of the class TRestBrowser, object skipped at offset 65
Error in <TBufferFile::CheckByteCount>: object of class TRestBrowser read too few bytes: 2 instead of 1335
-- Warning : -- W : The metadata version found on input file is lower than 2.2.1!                                        
-- Warning : -- W : metadata from input file will not be read                                                            

Yann

[jgalan]

Error (3) was also reported on a precedent post.

Error when using TRestBrowser. TRestBrowser inherits from TRestRun

System : MacOs REST version : v2.2.10 I get this error when launching REST_ViewG4Event(). Probably related to the fact that TRestBrowser inherits from TRestRun. Perhaps would be better that TRestBrowser simply contains fRun as a member of the class instead of inheriting from. Error in <TBufferFile::ReadClassBuffer>: Could not find the StreamerInfo for version 2 of the class TRestBrowser, object skipp ed at offset 88 Error in <TBufferFile::CheckByteCount>: object of class TRestBrowser read …

[ybedfer]

Concerning my THREE errors reproted above: I get them also w/ v2.2.9_dev.

Concerning your previous ticket: I had seen it… But my attention was caught by the first line :

System : MacOs 

=> Which I immediately connected w/ my bad past experience w/ ROOT on Mac: I have NOT been able to install a decent ROOT under the latest OS, viz. Mojave.

[jgalan]

I cannot reproduce problem (1) and (2).

If I use your original Setup_World.gdml, and change units from mm to cm in the RML. I visualize the geometry and a clear proton track.

Did you introduce any new changes in the geometry?

You may try to do TGeoManager::Import("Setup_World.gdml") and geo->Write("Geometry"); what do you get stored in the ROOT file?

Did you get any seg.fault at the end on restG4 execution?

If so, try to make clean and re-make both REST and restG4.

I am curious about the origin of this problem.

Further hints:

1. you may consider <angularDist type=“flux” …> or <angularDist type=“TH1D” … > on the proton generator.

2. Also, you may define as sensitiveVolume 1 of the silicon trackers volumes.

[ybedfer]

What fixes errors (1) and (2) is setting REST_VERBOSITY back to = normal!
=> Extreme debugging has weird side effects!..

@jgalan

1. you may consider <angularDist type=“flux” …> or <angularDist type=“TH1D” … > on the proton generator.

This is what I am going to work on next. What I have in mind is to implement the the 4-vectors of the 3 particles of the µp → µp event, which I have generated w/ a Si-based trigger from elsewhere. This, in a new generator type.

@jgalan

2. Also, you may define as sensitiveVolume 1 of the silicon trackers volumes.

But then, I miss the hydrogen, since I am allowed to have a single sensitive volume at a time. Right?
Then I agree, it’s something I may consider, in parallel. But to be useful I would need to have the FOUR Si’s of the telescope, so as to be able to trigger on the scattering angle.

And btw, I simplified my geometry (simplified for the purpose of this simple exercise I have reported on so far): I have in fact a TPC volume (between electrodes), w/ several daughter volumes inside, describing so many additional devices.
While I want instead to have only hydrogen as sensitive medium. The right way to go then is to create yet another daughter volume, which would be the sensitive one, and which I derive via the subtraction procedure that you, yourself, have implemented for the Cu vessel of PANDAX. Right?

[jgalan]

@ybedfer

What fixes errors (1) and (2) is setting REST_VERBOSITY back to = normal!
=> Extreme debugging has weird side effects!..

Still working for me when I do export REST_VERBOSITY=extreme

[jgalan]

@ybedfer

But then, I miss the hydrogen, since I am allowed to have a single sensitive volume at a time. Right?

I was thinking in case you launch the muon just behind silicon 1, then you put your sensitive volume on the silicon 4. Then, you are selecting tracks that necessarily went through 4 silicon detectors and the hydrogen target.

@ybedfer

The right way to go then is to create yet another daughter volume, which would be the sensitive one, and which I derive via the subtraction procedure that you

The subtraction method is very important when we use <generator type="volume" ...>.

Not sure about the right way to go, I guess it needs to be tested. In any case, I agree, you must simplify your geometry to the maximum. 1-single hydrogen volume would be enough at the beginning. Then, once you get some results, if you wish, you may increase geometry complexity, and try to see if there is any effect by introducing detail elements.