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.

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

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

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

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.

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

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.

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?

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

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.

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?

cvs log says mark rayner

..a gentle prod :)

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

works for Rob, not for Tim.

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

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.