hd_root output to potentially trim

[markdalton]

As requested by Sean. With HALLD_RECON_VERSION=4.16.2

1) This is for every thread, for every file.

JANA >>Run 41561 beam spot: x=0 y=0 z=65 dx/dz=0 dy/dz=0

2) What does this error mean? Is it important know about it? Can we either clarify the intent/importance or remove?

ERROR: request for channel number of inactive block! row 28 column 28 ERROR: request for channel number of inactive block! row 30 column 28

[mashephe]

The second error looks like it is generated by the FCAL geometry code. Someone is asking for the channel number of a block that does not exist in the detector. This error is printed when the specified row, column arguments point to a location outside the bounds of the detector.

Matt

---

This message was sent from my iPhone.

On Jun 13, 2020, at 10:48 AM, dalton notifications@github.com wrote:

 As requested by Sean. With HALLD_RECON_VERSION=4.16.2

This is for every thread, for every file. JANA >>Run 41561 beam spot: x=0 y=0 z=65 dx/dz=0 dy/dz=0

What does this error mean? Is it important know about it? Can we either clarify the intent/importance or remove? ERROR: request for channel number of inactive block! row 28 column 28 ERROR: request for channel number of inactive block! row 30 column 28

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[sdobbs]

Thanks Mark, a brief follow-up:

1. I think that this has been resolved in the current master. If not, I'm not sure where in halld_recon this is.

2. This is coming from some of the pre-select cuts. I need to add an if statement to protect against this.

[sdobbs]

Both of these should be resolved with my latest pull request - it would be good to have independent confirmation of this.

[aaust]

I checked the same run after PR #406 with 4 threads. I only saw 'beam spot' line once and no errors for inactive blocks.

3.) I observe quite many warnings of this kind at startup: JANA >>WARNING: Calling DSourceComboer::Reset_NewEvent() with repeated run number: 0

4.) The annoying error messages from the geometry of TOF, ComptonEMcal, DIRC and TRDGEM remain: src/JANA/JGeometryXML.cc:348 Node or attribute not found for xpath

[sdobbs]

Thanks! Closing. Comments below:

I checked the same run after PR #406 with 4 threads. I only saw 'beam spot' line once and no errors for inactive blocks.

3.) I observe quite many warnings of this kind at startup: JANA >>WARNING: Calling DSourceComboer::Reset_NewEvent() with repeated run number: 0

It's good that you see these warnings - these are probably older gen_amp files, where we were seeing occasional crashes. If i'm wrong, can take a look at this.

4.) The annoying error messages from the geometry of TOF, ComptonEMcal, DIRC and TRDGEM remain: src/JANA/JGeometryXML.cc:348 Node or attribute not found for xpath

I'll follow up with David on this, since we need a change in JANA.

[aaust]

I checked the same run after PR #406 with 4 threads. I only saw 'beam spot' line once and no errors for inactive blocks.

3.) I observe quite many warnings of this kind at startup:
JANA >>WARNING: Calling DSourceComboer::Reset_NewEvent() with repeated run number: 0

It's good that you see these warnings - these are probably older gen_amp files, where we were seeing occasional crashes. If i'm wrong, can take a look at this.

I did my test on raw data file hd_rawdata_041561_000.evio, using a few standard plugins: PLUGINS danarest,monitoring_hists,p2pi_hists,p3pi_hists,ppi0gamma_hists

[sdobbs]

Thanks for pointing this out - it looks like some non-physics events are getting passed into the comboing code. There's a few different possible solutions. One would be to prevent events with event_number = 0 to get into this part of the code. I could instead only allow events labeled as PHYSICS events, (i.e. collected with a usual trigger, not BOR or EPICS events). The latter seems more straightforward to me.