Update default DDDB tags to pick up LHCBCNDB-659

Minor additions to DDDB to speed up RICH simulation (does not affect reconstruction)

Name            Datatype
dddb-20171030   2010
dddb-20171030-1 2011
dddb-20171030-2 2012,2013
dddb-20171030-3 2015,2016,2017

changed title from Update default DDDB tags following to LHCBCNDB-590 to Update default DDDB tags to pick up LHCBCNDB-590

changed the description

• [2017-10-10 20:16] Validation started with lhcb-gaudi-head#725
• [2017-10-11 00:05] Validation started with lhcb-head#1624
• [2017-10-11 00:05] Validation started with lhcb-gaudi-head-noavx#158
• [2017-10-11 00:06] Validation started with lhcb-gaudi-head-noavx2#139
• [2017-10-11 00:06] Validation started with lhcb-lcg-dev4#308
• [2017-10-11 00:06] Validation started with lhcb-gaudi-head#1622
• [2017-10-11 00:06] Validation started with lhcb-lcg-dev3#308
• [2017-10-11 09:46] Validation started with lhcb-gaudi-head#726
• [2017-10-11 10:23] Validation started with lhcb-gaudi-head#727
• [2017-10-11 16:56] Validation started with lhcb-gaudi-head#728
• [2017-10-11 17:05] Validation started with lhcb-gaudi-head#728
• [2017-10-11 17:13] Validation started with lhcb-gaudi-head#728
• [2017-10-11 17:23] Validation started with lhcb-gaudi-head#728
• [2017-10-12 00:06] Validation started with lhcb-clang-test#733
• [2017-10-12 00:08] Validation started with lhcb-gaudi-head-noavx#159
• [2017-10-12 00:10] Validation started with lhcb-gaudi-head-noavx2#140
• [2017-10-12 00:10] Validation started with lhcb-gaudi-head#1623
• [2017-10-12 00:12] Validation started with lhcb-head#1625
• [2017-10-12 00:13] Validation started with lhcb-lcg-dev3#309
• [2017-10-12 00:13] Validation started with lhcb-lcg-dev4#309
• [2017-10-12 08:49] Validation started with lhcb-gaudi-merge#234
• [2017-10-12 11:10] Validation started with lhcb-gaudi-merge#235
• [2017-10-12 11:40] Validation started with lhcb-gaudi-head#729
• [2017-11-01 00:06] Validation started with lhcb-head#1645
• [2017-11-01 00:06] Validation started with lhcb-lcg-dev3#329
• [2017-11-01 00:06] Validation started with lhcb-clang-test#754
• [2017-11-01 00:06] Validation started with lhcb-gaudi-head-noavx2#160
• [2017-11-01 00:06] Validation started with lhcb-gaudi-head-noavx#179
• [2017-11-01 00:06] Validation started with lhcb-lcg-dev4#329
• [2017-11-01 00:06] Validation started with lhcb-gaudi-head#1643
• [2017-11-01 00:34] Validation started with lhcb-gaudi-head-noavx#179
• [2017-11-01 00:37] Validation started with lhcb-head#1645
• [2017-11-01 00:37] Validation started with lhcb-clang-test#754
• [2017-11-01 00:55] Validation started with lhcb-gaudi-head-noavx#179
• [2017-11-01 01:06] Validation started with lhcb-head#1645
• [2017-11-01 01:07] Validation started with lhcb-clang-test#754
• [2017-11-01 07:28] Validation started with lhcb-head#1645
• [2017-11-01 07:28] Validation started with lhcb-clang-test#754
• [2017-11-01 07:32] Validation started with lhcb-gaudi-head#1643
• [2017-11-01 07:53] Validation started with lhcb-gaudi-head#1643
• [2017-11-01 09:49] Validation started with lhcb-head#1645
• [2017-11-01 09:49] Validation started with lhcb-gaudi-head-noavx2#160
• [2017-11-01 09:57] Validation started with lhcb-gaudi-head#1643
• [2017-11-01 09:57] Validation started with lhcb-gaudi-head-noavx#179
• [2017-11-01 09:57] Validation started with lhcb-gaudi-head-noavx2#160
• [2017-11-01 09:59] Validation started with lhcb-head#1645
• [2017-11-01 10:02] Validation started with lhcb-clang-test#754
• [2017-11-01 14:29] Validation started with lhcb-gaudi-merge#268

marked as a Work In Progress

@seaso @jonrob I am not convinced that LHCBCNDB-590 ("Minor additions to DDDB to speed up RICH simulation") have no effect on the reconstruction. Compare the failing tests in https://lbnightlies.cern.ch/logs/tests/nightly/lhcb-head/1624/x86_64-slc6-gcc62-opt/Brunel/ (which included this MR, so the new DDDB tags) and https://lbnightlies.cern.ch/logs/tests/nightly/lhcb-head/1626/x86_64-slc6-gcc62-opt/Brunel/ which did not (ignore the repro2013-pa test that fails for another reason).

The diffs are not a big deal, but I want you to confirm that you DO expect a tiny effect also on the reconstruction, otherwise we have to dig deeper for the reason of this change..

Hello, One would expect similarity only on a statistical basis , in terms of performance. So they may not be identical to the last digit, especially if one runs on a small sample of events. For example, as I understand from some of these output files , the number of photons of 25.74 vs 25.75 is expected as these similar are within the errors. Another example I see ANN PID 0.0454 vs 0.0469 which are also similar within their errors. ( BTW, the effect of this update, together with those of the other ‘speed up’ options tried in Gauss can be seen in terms of the PID performance curves on page 21 of the talk I gave on 05-07-2016 in the gauss meeting (https://indico.cern.ch/event/543162/contributions/2228402/attachments/1304001/1947922/RICH-FastSimulation-July5-2016-Simulation.pdf) . Here one sees that the results from the different options are similar to one another for all practical purposes, but not ‘identical to one another’ to the last digit. ). Cheers, S.

@seaso, you misunderstand my question. In LHCBCNDB-590 it was said that it had NO effect on the reconstruction. I take that to mean that, when running the same program on the same events I would expect to get exactly the same results to the last digit. If it's not the case, then it does have an effect, even if it is statistically insignificant. That is important to understand, because there are times when changes that are expected to have no effect do have an unexpected effect due to bugs.

The plots you mention (and which I had seen) are irrelevant in this context, because they do not separate simulation (which is expected to be different, but not in a statistically significant way, as you correctly point out) from reconstruction which I was expecting to be unchanged. If you now say that a small effect is expected also in the reconstruction, then fine, I can go along with that, but please confirm that it is the case.

Like @cattanem I am surpised to see these differences. When I asked you about them in the rich meeting you told me there was no affect on the reconstruction, which to me, like Marco, means the results are expected to be bit wise the same. Statistically equivalent is not the same thing.

I cannot tell from the jira task exactly what you changed in the DDDB, and I now want to see this to judge whether what we see here is OK or not. Please can you post an exact record of what changed, a diff of the updated xml files before and after, so I can understand what quantities you touched in the update. Thanks.

Earlier I was assuming that these tests were run with the full chain Gauss-Boole-Brunel. At the moment I am also a bit puzzled. Nothing which is used in Brunel is expected to be changed with this DB update. So if the same Digi file is used as input to run the ‘same’ version of Brunel using same DB tag and with/without DB update, the results should be unchanged. For what it is worth, example log files obtained from a simple test by running RichDet with/without the DB update, are in kept in the area listed below. One sees from these log files that, as expected, the relevant parameters (mirror reflectivities) recorded and then printed by RichDet are “not affected” by this DB update. These are the parameters used in the reconstruction. The DB files in update, example original set etc are also listed below. I also did some 'diff' as listed below and searched if anything else is used in reconstruction and have not found anything so far. /afs/cern.ch/user/s/seaso/public/Simulation/CurrentLHCb/Updates-DB/2016-May/RichUpdates/RichSimFast/ /afs/cern.ch/work/s/seaso/public/Det/CurrentLHCb/myDDDB-CurrentLHCb2016Config/ /afs/cern.ch/user/s/seaso/public/Rich/CurrentRich/FastSimUpdateSaga/

Any more insight in this issue?

Sorry, I don't.

@seaso , please can you attached your diff to this report, rather than replying on AFS. I cannot read files on AFS where I am at the moment.

diffA.txtdiffB.txtdiffA.txtCurrentLHCb-Test-WithDbUpdatelogCurrentLHCb-GaussTest-WithDbUpdatelog

I don't have any further thoughts yet. I attach the log files and also diff files, apart from the list of tables/surfacelists etc. Anyway, if this turns out to be a new mystery issue, I can try to run a recent version of Brunel.

This also affects Moore to the extent that the number of decisions for quite a few lines change by +-2 (on a very special physics-enhanced sample). I attach the timing tables with old/new DDDB tag and diffs.

moore_timing.diff

moore_decisisons.diff

moore_timing_old.csv

moore_timing_new.csv

I have taken a look at @seaso 's diffs but nothing much jumps out at me.

@seaso I am afraid but I think you need to look into this. I don't think we can use the new DB tags in production until you have understood why this is happening...

I can try to run some recent version of Brunel to see what the issue is. S.

It turns out that, as usual, earlier I had misunderstood the list of reflectivity tables used by the reconstruction. As a result, there is a problem with this DB update and it needs a fix as listed in the area below. With this fix, the Brunel output would become unchanged as expected. I kept a couple of example log files with such outputs the same area. To use this fix in simulation, I also made a small backward compatible fix in GaussRICH. I shall try to get these two fixes sent with the usual procedures for update, in the coming days. /afs/cern.ch/user/s/seaso/public/logfile/brunel/

added 1 commit

• 0efde760 - Update default DDDB tags to pick up LHCBCNDB-659

Compare with previous version

unmarked as a Work In Progress

changed title from WIP Update default DDDB tags to pick up LHCBCNDB-590 to Update default DDDB tags to pick up LHCBCNDB-659

changed the description

merged

mentioned in commit lhcb-nightlies/LHCb@4f9f20d7

mentioned in commit 4f9f20d7

mentioned in commit 6ae45463

mentioned in merge request !932 (merged)

mentioned in commit e4faa3d8