Dear @sargyrop ,

the athena check on these jos failed on error due to low efficiency generation. I notice that the check was run at 13 TeV cm (which is different from what the jos are intended for - 5.02 TeV) and on 50 events. In my tests I noticed that the efficiency on small number of events is shown low but if run on the intended > 1000 events/job it increase at get close or above the required 98%. Is this 98% criterium not too strict? What about the other parameters of the checking run? Should I ask MC requestors to investigate efficiency of these jos?

p.s. I also was having problems with short time used for generation. 1k events runs ~2 min. I had to rerun them with 10k to get them accepted. But if cpu/event would be longer I would be in trouble to run tests interactively. Would it be possibly to reduce limits to allow running tests with max 3-6 hours/test? At the moment to avoid this check I always have to run test on 10k events.

Cheers, Andrzej

Hi @olszewsk

• low efficiency: yes perhaps the test is too strict I am not sure when/how this was implemented we should see whether to relax it (could you open a ticket so that we don't forget? I'll get back to it later in the day or tomorrow)

• testing with 10k events: I have an open MR here: !227 (closed) when this is merged you won't need to rerun. It would just see that you run 1k events and then if you put 10k in the jO the logParser would extrapolate the time to 10k

Let me know if I missed anything.

Hi @sargyrop ,

so for now could I resubmit branch with [skip athena] ? In the log from my test generation on 10k events HepMC efficiency check issues only a WARNING in the check on 2 of my jos: TestHepMC WARNING LOW EFFICIENCY! 98.4349% found, but at least: 99% expected. Maybe this should not be again verified in athena run in git on small number of events (and incorrect cm energy)?

Cheers, Andrzej

Hi @olszewsk

warnings will not cause logParser to fail (only errors). So I guess you want to do [skip athena] to not wait for !227 (closed) ?

This would be an option I guess, but already doing the MR and then just rebasing when !227 (closed) is merged would be preferable from my point of you (it's just a press of a button and we would test the code). But if you 're in a hurry [skip athena] would work yes. It's a known issue that you are facing.

Just to clarify, !227 (closed) improvement will help help with TestHepMC efficiency errors seen by athena check on git, when run with small number of events. This needs a different solution I believe. So I'll use the [skip athena] option.