additions in preparation to resonant HH/HY combination
I list here the lecons learned additions that we will need here, linked to the patch in my fork to explain better what I mean
-
HH part (task already existent)
-
To have the fit stable to all masses/analyses we used a custom factor in signal normalization, that would be taken into account in plotting here - That can be an external options instead of a hardcoded value as individual analyses do not need that [1] -
The final plotter here is completely external and here. Because of that with every plot we had a human readable file in json format as here that would be directly copied and interpreted in the external plotter (I am quite strong in keeping this workflow like this to interface well with B2G summary plots, where not all the analyses uses inference or fancy python output formats) - Before trying to implement anything here I want to see if it is possible to make the HEPData output of inference to be interpretable by the external plotter [1]. I mention this here because this json file is practically used in many of the following patches. -
We did not had snapshot step implemented in the eft workflow (where the resonant task is located on the fork). To circumvent that and make fit stable I implemented a signal injection in a way that: running once expected a json file (the above-mentioned one) and when running the observed that would look for the expected json file and use to tweak fit borders as here (that was a problem specially to boosted analyses) -- before implementing anything here I would like someone to test the B2G-23-005 fit with snapshot and without signal injection to see if any action still needed. -
Initially I made an option to be possible to skip some masses here, or run only a few. As in the way I did that would change the hash of the Limits step output that was not used, even if it would have been handful for debugging. We gave more handmade ways to debug couple of failing masses. -
I was finding masses in datacard by pattern rather than the mass itself as full naming convention (there is a good reason, related with HY first bullet). That would make confusions eg of 300
with3000
, that in the end we would solve by hand in the json file before the external plotter :-p. That is something to pay attention if in master we are doing similar thing. -
For GOF and impacts we needed the dummy_model. Some of the working people just commented out the hh_model calling from the WS making for the GOF/impacts workflow call to not maintain other inference installation hehe... I tried to maintain the dummy_model branch up to date with master, but I am not sure if that went well and I think I broke that branch. It would be good if someone tests it [1] before asking to merge to master again. -
A place where we would do a lot of mistakes in GOF and impacts was to have to keep in mind that signal would have to be injected as external command part AND would not quite be the one of the json file, but one taking into account the real signal normalization here. I am not sure if there is an automatic solution to this other than being super attentive on construction of commands (and keep those under version control)
-
-
HY part - Implement the task in resonant workflow :-D
-
In the fork I did as lawyers of Resonant plot here (reading the json file mentioned above). I know you would not like to do the link to a plot results, rather to the limits files. But it might be a good idea to make that layered in Resonant for a practical debugging reason -- in debugging fits it was quite handy to be able to run MX-by-MX from the PlotResonantLimitsHY
task using something like--datacard-pattern "datacard_mass_X400_Y(.+)\.txt
-
There are some more stuff to pay attention to be added here [TO BE CONTINUED]
-
-
WARNING: I do not have time now to be thorough, but list the most important ones / the ones more fresh in my memory.
- This description and list can be evolving --> When it is not evolving anymore that warning will be removed
-
What is marked with [1] is also useful to the HVT combination (that have shorter timescale), and therefore also interesting to Yihui or Sitian implement as feature and link that in this issue
Edited by Alexandra Carvalho Antunes De Oliveira