Add jet and fatJet jsons for 2022-preEE and 2022-postEE

[izisopou]

In this PR we upload the jet_jerc.json.gz and fatJet_jerc.json.gz files for Summer22_22Sep2023 and Summer22EE_22Sep2023.

• jet_jerc_Summer22_22Sep2023_JCV2_JRV1.json.gz and fatJet_jerc_Summer22_22Sep2023_JCV2_JRV1.json.gz: Based on Summer22_22Sep2023_V2 JEC and Summer22_22Sep2023_JRV1 JER.
• jet_jerc_Summer22_22Sep2023_JCV3_JRV1.json.gz and fatJet_jerc_Summer22_22Sep2023_JCV3_JRV1.json.gz: Based on Summer22_22Sep2023_V3 JEC and Summer22_22Sep2023_JRV1 JER
• jet_jerc_Summer22EE_22Sep2023_JCV2_JRV1.json.gz and fatJet_jerc_Summer22EE_22Sep2023_JCV2_JRV1.json.gz: Based on Summer22EE_22Sep2023_V2 JEC and Summer22EE_22Sep2023_JRV1 JER.
• jet_jerc_Summer22EE_22Sep2023_JCV3_JRV1.json.gz and fatJet_jerc_Summer22EE_22Sep2023_JCV3_JRV1.json.gz: Based on Summer22EE_22Sep2023_V3 JEC and Summer22EE_22Sep2023_JRV1 JER

Moving from the JCV2 to the JCV3 versions, we fixed an asymptotic discontinuity in the L2Relative JEC files. Related PRs are: #206 and #207 .

In the files attached, we compare the JCV2_JRV1 (currently in jsonPOG-Integration) vs JCV3_JRV1 (to be uploaded to jsonPOG-Integration) JSONs:
out_JetJSON_2022EE_BeforeVsAfterAsymptFix_PtEta.pdf
out_JetJSON_2022_BeforeVsAfterAsymptFix_PtEta.pdf
out_FatJetJSON_2022EE_BeforeVsAfterAsymptFix_PtEta.pdf
out_FatJetJSON_2022_BeforeVsAfterAsymptFix_PtEta.pdf
As expected, everything is identical except for the specific eta bins in the L2Relative where the fits were reproduced in order to fix the asymptotic discontinuities.

The JCV3_JRV1 versions are expected to replace the JCV2_JRV1 versions in jsonPOG-Integration, once this PR is approved and merged.

cc: @ravindkv

[ravindkv]

Hi @izisopou, thanks a lot.

It would be consistent if we can keep the same directory structure as that of json-pog e.g.

• 2022/jet_jerc.json.gz and so on.
• the JCVx_JRVy versioning is conveneint to know the versions used but then we sometimes use the JR from different years to different years or we might need to use PtResolution from different years. In that case it would be confusing what x and y means in the names. Therefore, we can keep the file name clean and drop JCVx_JRVy, we can anyway see the versions inside the json files. For book keeping we can describe in the MR the exact version used.

What is happening for FlavourQCD for the low pT regions:

This we see for both years and jet algos

[izisopou]

Hi @ravindkv ,

If we retain the same directory structure as in jsonPOG-integration, we would lose the ability to keep all JSON versions for a specific campaign in a single, consolidated location. Furthermore, directly copying that structure would effectively duplicate the entire jsonPOG-integration repository here. If full duplication is indeed the goal, then we can do that, but I do not think it is needed; we can just continue using the jsonPOG-integration repo. Rather than simply moving the POG/JME folder from jsonPOG-integration, my intention was to adopt a structure consistent with the other directories already used within the JECDatabase (textFiles/, tarballs/, SQLiteFiles/). That way, we would here have an archive of all the JSON files (same as we do for txt, db and tar files), while the most recent/recommended ones would still be found in the jsonPOG-integration repository.

Regarding the JR versions, we can think this a bit more. For example, if we have Summer23BPixPrompt23_JRV1 in JRDatabase and we want to use it for 2024, we can copy these files to a Summer24Prompt24_JRV1 version, same as we do for JEC. Then, we would have a JSON file with the name of Summer24Prompt24_JCV1_JRV1. The analyzers would still be using the jet_jerc.json.gz from jsonPOG-Integration; the file here would only serve for book-keeping purposes. Please, let me know if I am missing something.

For FlavorQCD I am not sure. We will have to check the corresponding txt file as this has not changed in this specific PR. I applied the JSON files to a 2025C dataset. Could this be the cause of this problem?

[ravindkv]

Hi @izisopou , thanks for the thoughts.

• Fine for me on the naming. Indeed keeping all older versions would be helpfull.
• On a different note, I see one minor inconsistency which is keeping the json inside JECDatabase when the json has both JC and JR. Off course we can not have same foder in the JRDatabase.
• The trend for FlavourQCD in the low pT is consistent with the text file:

[FlavorQCD]
{1 JetEta 1 JetPt "" Correction JECSource}
-5.4 -5.0 150 9.0 0.0160 0.0160 11.0 0.0160 0.0160 13.5 0.0160 0.0160 16.5 0.0160 0.0160 19.5 0.0160 0.0160 22.5 0.0160 0.0160 26.0 0.0160 0.0160 30.0 0.0160 0.0160 34.5 0.0144 0.0144 40.0 0.0130 0.0130 46.0 0.0118 0.0118 52.5 0.0109 0.0109 60.0 0.0102 0.0102 69.0 0.0095 0.0095 79.0 0.0088 0.0088 90.5 0.0081 0.0081 105.5 0.0074 0.0074 123.5 0.0067 0.0067 143.0 0.0061 0.0061 163.5 0.0055 0.0055 185.0 0.0050 0.0050 

same value (16e-03) for pt <30. It is just that the plot is zoomed too much that is why we see big error bars.

[izisopou]

Hi @ravindkv ,

Thank you for your reply and for checking the FlavorQCD text file, everything seems to be reasonable indeed. If you agree, I can open a MR in jsonPOG-Integration with the updated jsons.

Regarding this repo, I agree with your comment about the inconsistency. Technically, we would need a JERCDatabase for the JSON files, and maybe that was the reason why the jsonFiles folder was not used so far in the first place. On one hand, keeping an archive of all JSON files will definitely be useful, on the other hand I worry we may confuse analyzers with this repository. If we proceed with merging this PR we may have to explicitly make clear that this folder is only an archive and the JSON files to be used should be taken from jsonPOG-Integration (hence my update on the README file). Another option would be to transfer the jsonFiles folder in a private JERC gitlab repo just for us and JME, and keep jsonPOG-Integration as the only public place for JERC JSON files.

[ravindkv]

Hi @izisopou, thanks a lot.

• Please go ahead and make the MR to json-pog

• Since the JECDatabase has alread grown too big, pusing the jsons there would make it even bigger due to the fact that we can not symlink anything in the json so every new file will be as big as the previous one.

• I think we can have a gitlab repo for jsons. Let us discuss more with others (@anmalara, @dsavoiu, @nurfikri89) and see if they have any openion.