Added ART tests for 25x100 pixel pitch and IDPVM postprocessing.

1. Added 25x100 pixel pitch tests to the set of r21.9 ART tests

2. Added an IDPVM post-processing closure test to r21.9 ART tests

merged

mentioned in commit 91eace54

CI Result SUCCESS

	Athena
externals
cmake
make
required tests
optional tests

Full details available at NICOS MR-20647-2019-01-25-19-53
Athena: number of compilation errors 0, warnings 0
CI Jenkins server is switched to https://atlas-sit-ci.cern.ch. It is accessible world-wide (behind CERN SSO). In old links to Jenkins server aibuild080.cern.ch:8080 should be replaced with atlas-sit-ci.cern.ch For experts only: Jenkins output [CI-MERGE-REQUEST 32783]

At the moment all the tests added here are failing straight away due to the lack of an input file:

ls: cannot access last_results_muons_100GeV: No such file or directory
+ exec ls -lL '/eos/atlas/atlascerngroupdisk/data-art/grid-input/InDetSLHC_Example/inputs/EVNT.09244578.*.pool.root.1'
ls: cannot access /eos/atlas/atlascerngroupdisk/data-art/grid-input/InDetSLHC_Example/inputs/EVNT.09244578.*.pool.root.1: No such file or directory

I think this is because you should be accessing them from cvmfs rather than eos e.g. here.

I also notice that the RAWtoALL workflow is not being used, so I assume that these tests were copied based on old versions of the ART tests before we made that fix? I would recommend that you take a look at the newest versions and base the reconstruction on those, otherwise you will see the previously discussed issues in the strip residuals due to the problems with persistifying the row index.

I also have a question on the naming. Why do these tests have "2020" in the name? I understand that for the moment the "fixed" reference (we should also have here comparisons against the last build too) was made in 20.20, but that is the case for all our tests at the moment. The plan would be that once we have a fixed reference (for example, this can be soon if our plan to make a first 21.9 release within a few weeks goes as planned) this will be a good candidate for a fixed reference. After this point having "2020" in the name will be very confusing.

A last point is that since (at the moment) Merge Request reviews are not being enforced prior to MRs being accepted, I think it would be worthwhile always adding a few experts to the MRs so that they can see what is proposed. For example:

@ncalace @swaban @npetters @asalzbur @goblirsc @lmijovic

The post-processing test also seems to have the same problems with cvmfs vs eos file access.

In general though it is not so clear that this test actually belongs in this package. It seems this package is a generic test on the replicability of IDPVM results, when using post-processing to merge result, is that correct? If so, it doesn't seem to have much to do with ITK reconstruction specifically, so I wonder if this should rather be somewhere else than InDetSLHC_Example?

Hello @nstyles yes, correct, it is a generic test on the replicability of IDPVM results, when using post-processing to merge result . I agree InDetSLHC_Example is not an optimal fit. The best suggestion that comes to my mind is to create a test directory within the IDPVM itself. Other ideas?

@dbiswas it was not clear to me at any point that your postprocessing test was either of stable or reliable. On 24th you emailed us your updated results which were not fully conclusive. There are two follow-up questions from the 23rd meeting below. If you estimate you have/are close to having a fully working test(?), I guess it is ok you went ahead with the merge request. But we should ensure to have a correct test by the end of your QT.

Best, Liza

As per 23rd meeting minutes [https://indico.cern.ch/event/784490/ ] we asked you for

1. list of histograms which show up in rel. but not in absolute tests and
2. check for plots which report IDPVM post-processing warnings whether these are all plots to be handled by post-processing. In case of any other plots (handled by hadd) this would indicate a need for further tuning of rounding parameter (1e-4) used in the checks.

@nstyles I had found that eos vs cvmfs bug and fixed it in my local copy. I have not yet submitted another merge request because I was putting it in several trial runs to make sure everything works. Also, I will have to include the RAWtoALL switches as you pointed out. I will remove the "with_2020" part from the scripts names in my next MR.

@lmijovic The situation has changed a lot since the last meeting as I informed you in my email thread. Now there is no difference in the outcome of relative and absolute tests. Both of them have 30 same failed plots. I will send you the detailed report as PDF slides. The rounding parameter (1e-4) seems to be working perfectly. The 30 failed histograms have exactly same bin content but very different (~ 10 times) bin error. So, they should have failed irrespective of what error tolerance we choose.

Hi @dbiswas

Thanks for the update. NB that you can make a Merge Request and put it in "Work In Progress" status until it is ready if you want people to be able to take a look and comment on it.

mentioned in merge request !20772 (merged)