Project

General

Profile

Bug #1063

Tracker1.dat geometry broken

Added by Lane, Peter about 9 years ago. Updated about 9 years ago.

Status:
Closed
Priority:
Normal
Category:
Simulation
Target version:
Start date:
25 July 2012
Due date:
% Done:

100%

Estimated time:
0.00 h
Workflow:
New Issue

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.


Related issues

Related to MAUS - Bug #1065: A single tracker geometry module must use "PropertyInt Tracker 0"OpenHeidt, Christopher27 July 2012

Actions
#1

Updated by Lane, Peter about 9 years ago

This is the trunk, BTW.

#2

Updated by Rogers, Chris about 9 years ago

  • Category set to Simulation
  • Assignee set to Heidt, Christopher
  • Target version set to Future MAUS release
#3

Updated by Rogers, Chris about 9 years ago

Should use Squeal exception, not assert

#4

Updated by Rogers, Chris about 9 years ago

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.

#5

Updated by Heidt, Christopher about 9 years ago

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.

#6

Updated by Heidt, Christopher about 9 years ago

  • 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.

#7

Updated by Lane, Peter about 9 years ago

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).

#8

Updated by Lane, Peter about 9 years ago

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.

#9

Updated by Dobbs, Adam about 9 years ago

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...

#10

Updated by Heidt, Christopher about 9 years ago

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.

#11

Updated by Lane, Peter about 9 years ago

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:

  1. The code should not core dump because of the assertion failure (i.e. use Squeal)
  2. 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.

#12

Updated by Lane, Peter about 9 years ago

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.

#13

Updated by Rogers, Chris about 9 years ago

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.

#14

Updated by Rogers, Chris about 9 years ago

  • Target version changed from Future MAUS release to MAUS-v0.3.2
#15

Updated by Heidt, Christopher about 9 years ago

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