Project

General

Profile

Support #499

G4MICE - Unable to run Step1Ensemble (error in TofCalibrationMap?)

Added by Carlisle, Timothy almost 11 years ago. Updated almost 11 years ago.

Status:
Rejected
Priority:
Normal
Assignee:
Fletcher, Rob Roy
Category:
TOF
Target version:
Start date:
03 June 2011
Due date:
% Done:

0%

Estimated time:
Workflow:

Description

I'm trying to run Step1Ensemble with some of the run (2177) data from last summer, in order to then have a real beam with which to simulate through Step 4. I'm using the default datacards, in the latest G4MICE release, but there's a bug.

gdb indicates a problem within TofCalibrationMap. Any help would be much appreciated! Thanks

MICEStage1/Stage1.dat
DAQ Verbose Level set to 3 =========== TofRec ============
CalibrationMode 0
Trigger from - TOF1
MakeSpacePiontCut = 500 ps
FindTriggerPixelCut = 500 ps ===============================
  • ERROR in TofCalibrationMap::InitializeFromCards() ***
  • PmtKey: station 2, plane 0, slab 0, pmt 0 is not presented in the current configuration ***
  • Unable to initialize TofCalibrationMap ***
  • exit ***

Files

cards.in (209 Bytes) cards.in Rogers, Chris, 20 July 2011 10:27
02204.000 (87.3 MB) 02204.000 Rogers, Chris, 20 July 2011 10:27
#1

Updated by Karadzhov, Yordan almost 11 years ago

As you can see from the error message, the problem is that "station 2, plane 0, slab 0, pmt 0 is not presented in the current configuration". This is because you use MICEStage1/Stage1.dat in your cards.in file. But TOF2 detector is not presented in this configuration.
However you analyse a run where TOF2 detector exists and we have a data recorded by this detector. TOF2 detector is presented also in the calibration you are trying to load.
This bug was reported long time ago but wasn't fixed by the people responsible for the geometry in G4MICE. In fact Stage1 configuration is quite far from the reality.

Easy solution of the problem will be just to use
MICEStage2/Stage2.dat
instead of
MICEStage1/Stage1.dat
in your cards.in file.

#2

Updated by Tunnell, Christopher almost 11 years ago

Hey Yordan, Just for the record: we actually don't have anybody responsible for the geometry. Oh well.

#3

Updated by Tunnell, Christopher almost 11 years ago

What's the solution here? (Can the TOF code report an error that it can't process and not exit?) What geometry did Mark Rayner use? How do we find somebody to own the geometry...

#4

Updated by Karadzhov, Yordan almost 11 years ago

The solution is to edit Stage1.dat and to include TOF2 or just to use Stage2.dat where TOF2 already exists.

#5

Updated by Tunnell, Christopher almost 11 years ago

That's not an optimal solution. The calibration code shouldn't crash. And the geometry should be fixed (probably it falls into the TOF group's responsibility since there's nobody owning our geometry). There are two different tasks.

It's not your fault but it's absolutely insane that we just took this much data and don't have a geometry that represents the configuration of the detectors for our step 1 data. It's been a year.

#6

Updated by Tunnell, Christopher almost 11 years ago

(When I say 'fixed' I mean in the repository. So half of the solution is what you say: 'add TOF2 to step1')

#7

Updated by Karadzhov, Yordan almost 11 years ago

The calibration code doesn't crash. It gives proper error message and then exits. And this is exactly what it has to do.

Also I don't think the implementation of the geometry for Step1 is responsibility of the tof group.

#8

Updated by Tunnell, Christopher almost 11 years ago

Ignoring the issue of nobody being assigned to the geometry.

Are you the person who wrote Step1Ensemble? If so, can you make the default cards.in produce something other than an error?

For robustness, can you make the TOF calibration so it gives an error message (like it does) but does not exit/crash so we can still get physics out of TOF0 and TOF 1 for Step 1? I would really appreciate it. Do you mind doing this?

#9

Updated by Carlisle, Timothy almost 11 years ago

using Stage2.dat appears to bypass the problem. However a segmentation fault kicks in shortly after, again default datacards with latest release, unable to locate for 'atomicity.cc'.

MICEStage2/Stage2.dat
DAQ Verbose Level set to 3 =========== TofRec ============
CalibrationMode 0
Trigger from - TOF1
MakeSpacePiontCut = 500 ps
FindTriggerPixelCut = 500 ps ===============================
1
Creating the equipment map ...
102 0x8903260 V1290 0x897d460
111 0x8902210 V830 0x897b218
120 0x8905700 V1724 0x897d8b0
121 0x8901868 V1731 0x897d908
128 0x88cd430 PCI6254 0x897d960
Equipment Map count : 0x1
... Done

Program received signal SIGSEGV, Segmentation fault.
0xf4b231c9 in _gnu_cxx::_exchange_and_add (__mem=0xfffffffc, __val=-1) at atomicity.cc:41
41 atomicity.cc: No such file or directory.
in atomicity.cc

Yordan can you advise?

Thanks for helping me out with this

#10

Updated by Karadzhov, Yordan almost 11 years ago

I have no idea what this error means. Who is the author of the Step1Ensemble application? I think the author is the right person to address the problem.

#11

Updated by Rogers, Chris almost 11 years ago

  • Assignee changed from Karadzhov, Yordan to Rayner, Mark

Mark - are you available to help Tim?

#12

Updated by Tunnell, Christopher almost 11 years ago

Tim: what does cvs log on those files say? Who was the person who created them? It seems like dead code... is there documentation on it anywhere?

#13

Updated by Rogers, Chris almost 11 years ago

cvs log says mark rayner

#14

Updated by Carlisle, Timothy almost 11 years ago

..a gentle prod :)

#15

Updated by Rogers, Chris almost 11 years ago

Is this still open? If so, can Tim speak to Rob Fletcher who got it running?

#16

Updated by Tunnell, Christopher almost 11 years ago

works for Rob, not for Tim.

May be 64-bit issues? He's testing.

#17

Updated by Rogers, Chris almost 11 years ago

  • Target version set to Future MAUS release

I had a problem running 64 bit. My guess is something dark in the REALData. Get output like:

RooFit v2.95 -- Developed by Wouter Verkerke and David Kirkby
                Copyright (C) 2000-2008 NIKHEF, University of California & Stanford University
                All rights reserved, please read http://roofit.sourceforge.net/license.txt

DAQ Verbose Level set to 3

But then the code just fills up my 3 GB of RAM. Works fine with same cards, input file on 32 bit. Officially G4MICE doesn't support 64 bit, so this is acceptable - but evil! I hope we don't have anything like this in MAUS. Tim can you check in 32 bit? Do you have access to 32 bit machine?

#18

Updated by Rogers, Chris almost 11 years ago

Update - added the input files

#19

Updated by Carlisle, Timothy almost 11 years ago

  • Assignee changed from Rayner, Mark to Fletcher, Rob Roy

I haven't got it running yet - Rob can you take a look at checking in 32 bit? If not I can tackle it when back in Oxford.

#20

Updated by Fletcher, Rob Roy almost 11 years ago

Ive have got this working on 2 32 bit machines now using the files that Chris Rodgers posted. I think that Chris and I tried it on a 64 bit machine and it was failing so I think that this may be limited to 32 bit for the moment.

#21

Updated by Tunnell, Christopher almost 11 years ago

  • Status changed from Open to Rejected

64 bit is not supported for g4mice.

Also available in: Atom PDF