first commit of LFHCAL benchmarks

[steinber]

This is based on the zdc_lyso examples but should work once I iron out a few things. I've cleared with Dima that I'll work out those things in the PR discussion.

Briefly, what does this PR introduce?

Benchmarks for LFHCAL, using a Snakemake workflow based on zdc_lyso example.

What kind of change does this PR introduce?

• Bug fix (issue #__)
• [ X] New feature (issue #__)
• Documentation update
• Other: __

Please check if this PR fulfills the following:

• [ X] Tests for the changes have been added
• [ X] Documentation has been added / updated
• [ X] Changes have been communicated to collaborators

Does this PR introduce breaking changes? What changes might users need to make to their code?

None

Does this PR change default behavior?

It adds the LFHCAL benchmarks to detector_benchmarks, so yes it may have an impact on the centralized benchmark production.

[steinber]

Oh I see - this was for testing on the CI side. I'm trying again wit a fresh branch checkout to see if the plots are empty in that case.

[steinber]

Hi @veprbl - I just ran straight from the branch (snakemake --cores 4 lfhcal_local) with 100 events and all plots were filled. Not sure how to square what you're seeing and what I am seeing...

[veprbl]

Hi @veprbl - I just ran straight from the branch (snakemake --cores 4 lfhcal_local) with 100 events and all plots were filled. Not sure how to square what you're seeing and what I am seeing...

Are you running everyting with Snakemake? Which version of the geometry do you source?

[veprbl]

Oh I see - this was for testing on the CI side. I'm trying again wit a fresh branch checkout to see if the plots are empty in that case.

That should not matter for local testing.

[steinber]

I was using epic-main, since I assumed it was "nominal" - not so?

[veprbl]

detector_benchmarks also

detector_benchmarks/.gitlab-ci.yml

Line 111 in 8116047

- source /opt/detector/epic-main/setup.sh

[steinber]

So the checks failed, but it's not an LFHCAL problem, but "ecal_gaps" raising a divide-by-zero error.

[steinber]

Something is very weird - when I go into the "sim:lfhcal: [neutron, 20GeV]", and check the log, the simulation is all 500 MeV electrons. This may be part of the problem.

[veprbl]

So the checks failed, but it's not an LFHCAL problem, but "ecal_gaps" raising a divide-by-zero error.

Correct. That might be a relevant issue.

Something is very weird - when I go into the "sim:lfhcal: [neutron, 20GeV]", and check the log, the simulation is all 500 MeV electrons. This may be part of the problem.

Interesting. I will try to disable download cache, in case it causes wrong steering files to be retrieved from it.

[steinber]

So the checks failed, but it's not an LFHCAL problem, but "ecal_gaps" raising a divide-by-zero error.

Correct. That might be a relevant issue.

Relevant to ECAL :)

Something is very weird - when I go into the "sim:lfhcal: [neutron, 20GeV]", and check the log, the simulation is all 500 MeV electrons. This may be part of the problem.

Interesting. I will try to disable download cache, in case it causes wrong steering files to be retrieved from it.

Can you confirm that I'm not hallucinating this?

[steinber]

Oh well - once the tests are restarted, I can't see the old output. Fingers crossed and I'll check in an hour.

[veprbl]

Oh well - once the tests are restarted, I can't see the old output. Fingers crossed and I'll check in an hour.

No, it's all there. You can always open previous pipeline, and if jobs are re-run the previous logs are also there.
https://eicweb.phy.anl.gov/EIC/benchmarks/detector_benchmarks/-/pipelines/104131

So the checks failed, but it's not an LFHCAL problem, but "ecal_gaps" raising a divide-by-zero error.

Correct. That might be a relevant issue.

Relevant to ECAL :)

Relevant to benchmarks that fail to get correct steering files ;)

Something is very weird - when I go into the "sim:lfhcal: [neutron, 20GeV]", and check the log, the simulation is all 500 MeV electrons. This may be part of the problem.

Interesting. I will try to disable download cache, in case it causes wrong steering files to be retrieved from it.

Can you confirm that I'm not hallucinating this?

I did, it shows e- in that ddsim debug output.

[steinber]

I just checked the LFHCAL sim jobs and the several I checked at random did match between the job name (neutron, 5 GeV) and the actual particle simulated.

[steinber]

Plots aren't empty anymore but there are a few things to check before I'm happy - still I think it's worth merging just to have something in place.

[steinber]

Still more to tweak, but the energy resolution plots for gamma, neutrons, pi- are not absurd anymore (but I need to have plots for the measured energy scale now too, and a quick determination of EM/HAD weights).

[steinber]

Hi @veprbl and @wdconinc - a whole lot of checks failed just now, and not just in LFHCAL benchmarks (but yes one of mine failed too). Is this something I need to address or something upstream?

[veprbl]

We somehow overfilled scratch space on eicweb. I will restart pipeline once this is resolved.