Bug #1063
Tracker1.dat geometry broken
Added by Lane, Peter over 10 years ago.
Updated over 10 years ago.
Description
Using the following geometry with simulate_mice.py:
Configuration SingleStation
{
Dimensions 30000.0 30000.0 30000.0 mm
PropertyString Material AIR
PropertyDouble G4StepMax 5.0 mm
Module Tracker/Tracker1.dat
{
Position 0.0000 0.0000 12634.4100 mm
Rotation 0.0 0.0 90.0 deg
}
}
I get the following error after 5 spills:
TRANSFORM/MERGE/OUTPUT: Processed 5 spills so far, 1 spills in buffer.
python: src/common_cpp/DetModel/SciFi/SciFiSD.cc:96: virtual G4bool SciFiSD::ProcessHits(G4Step*, G4TouchableHistory*): Assertion `abs(chanNo-old_chanNo) < 2' failed.
Aborted (core dumped)
Putting in a debug statement into SciFiSD right before this line yields,
DEBUG SciFiSD::ProcessHits(): chanNo = 3 old_chanNo = 177
It would also be nice if MAUS didn't core dump just because an assertion failed.
- Category set to Simulation
- Assignee set to Heidt, Christopher
- Target version set to Future MAUS release
Should use Squeal exception, not assert
Added a flag to the environment to control assert handling. Note that it is now disabled by default which is a change to the previous behaviour.
A few things off the top of my head while I wait for MAUS to run some tests on this. Have you tried using Tracker0.dat? Tracker0.dat and Tracker1.dat only differ in the setting PropertyInt Tracker 0 and PropertyInt Tracker 1. Code be if you are only using a single tracker the code will be looking for Tracker 0 and not finding it. Also have you changed your datacard to represent a single station? Look for the following lines:
SciFinPlanes = 3
SciFinStations = 5
SciFinTrackers = 2
You should change these to represent your system.
Also, did you change the number of stations in the tracker 1 file, not that I think it will mess up your code. But you know Tracker 1 is a single tracker comprised of 5 stations, not a single station.
- Status changed from Open to Closed
- % Done changed from 0 to 100
- Estimated time set to 0.00 h
Okay I tried running with Tracker 0 and had no problems up to 8 spills of 150 particles. Tried running with Tracker 1 and crashed right away with the message:
python: src/common_cpp/DetModel/SciFi/SciFiSD.cc:95: virtual G4bool SciFiSD::ProcessHits(G4Step*, G4TouchableHistory*): Assertion `abs(chanNo-old_chanNo) < 2' failed.
Aborted
Sounds like this is our problem!
Solution: Either change the entry "PropertyInt Tracker 1" in Tracker1.dat to "PropertyInt Tracker 0" or use Tracker0.dat in your system.
With all due respect, I find this solution unsatisfactory. First of all, as Chris R. said, this should use Squeal not assert. The code should not core dump because of this!
Secondly, this error message is completely useless in this context. It does not tell me what the core problem is, and it gives me absolutely no clue as to how to fix whatever that problem is (and I still don't understand what that is).
I should add that my understanding is that the single station test used one of the stations from Tracker 1, so I find it reasonable to be able to have SciFi hits be identified as coming from Tracker 1. If I hack it to identify as Tracker 0 just to get it working then my simulated data will be mislabled.
The single station test code was not to my knowledge intended for the trunk, so I not sure how this has come up. As the single station is the first tracker object encountered by the beam it make more sense to label it 0 rather than 1. Better yet, incorporate it as it is, which is not as an actual tracker at all, but as a separate detector in its own right, which does not require a tracker label. Agree that error messages should of course explain what has gone wrong...
hey Peter I'll look at this again to try and address your issues. Right now our counting convention is to start at zero and count up, so if there is only one tracker in the beam then that would be ""PropertyInt Tracker 0". The geometry file you use should describe the system, not the counting method.
The single station test used a spare tracker station. Other than station 5 in Tracker0 all the tracker stations are identical, additionally, in the single station run there are no trackers in the beam, so I don't understand the need to label something Tracker1.
Great, thanks for clarifying the labeling. Still, I think this issue should be reopened until the code gracefully handles this. There are also two separate issues here:
- The code should not core dump because of the assertion failure (i.e. use Squeal)
- The code should complain specifically if I try to use an invalid "PropertyInt Tracker" value
The first one should be quite easy to fix. I will create a new issue about the second item.
Adam, I'm ignorant of any single station test code. This came up ultimately because Chris Rogers wanted me to test my global reconstruction code on the single station data. To do that I need a geometry to simulate with. In the process of trying to get something working I was directed towards the geometry files in src/legacy/FILES/Models/Modules/. We don't have the CAD-based geometry files yet, so as far as I know this is the best I have to work with.
Adam:
The single station test code was not to my knowledge intended for the trunk, so I not sure how this has come up
I was talking about the control room code in this instance, so reducers etc.
- Target version changed from Future MAUS release to MAUS-v0.3.2
I'll be happy to change how this works, if someone can point me to an example of how Squeal works or some documentation. I could also use a try catch and a cerr, will this work as well?
Also available in: Atom
PDF
