Reimplement ATLAS WPWM 7TeV 36PB

[ecole41]

Functions haves been added to produce the data central, kinematic and uncertainties yaml files for this dataset.

Old vs New Data Report

https://vp.nnpdf.science/6-mHiiJJTcC5Mf86u4NJ2g==/

Compatabiliy Check

[In]:from validphys.api import API
import numpy as np
 
inp1 = {"dataset_input": {"dataset": "ATLAS_WPWM_7TEV_36PB_ETA"}, "theoryid": 40_000_000, "use_cuts": "internal", "t0pdfset": "NNPDF40_nnlo_as_01180", "use_t0": True}
inp2 = {"dataset_input": {"dataset": "ATLASWRAP36PB", "variant": "legacy"}, "theoryid": 40_000_000, "use_cuts": "internal", "t0pdfset": "NNPDF40_nnlo_as_01180", "use_t0": True}

covmat1 = API.covmat_from_systematics(**inp1)
covmat2 = API.covmat_from_systematics(**inp2)
 
t0_covmat1 = API.t0_covmat_from_systematics(**inp1)
t0_covmat2 = API.t0_covmat_from_systematics(**inp2)
 
result = np.all(np.isclose(covmat1, covmat2))
result_2 = np.all(np.isclose(t0_covmat1, t0_covmat2))

print('covmat', result)
print('t0_covmat', result_2)

[Out]:LHAPDF 6.5.4 loading [/Users/ellacole/miniconda3/envs/nnpdf_dev/share/LHAPDF/NNPDF40_nnlo_as_01180/NNPDF40_nnlo_as_01180_0000.dat](https://file+.vscode-resource.vscode-cdn.net/Users/ellacole/miniconda3/envs/nnpdf_dev/share/LHAPDF/NNPDF40_nnlo_as_01180/NNPDF40_nnlo_as_01180_0000.dat)
NNPDF40_nnlo_as_01180 PDF set, member #0, version 1; LHAPDF ID = 331100
covmat True
t0_covmat True

[scarlehoff]

I think it is better to finish the ones that are already started and then move to the more weird datasets ^^U

When the data don't match, try to take the ratio and check whether the difference is just normalization. Some of the old datasets were normalized for bin size / total cross section / other stuff.

[scarlehoff]

Hi @ecole41 I've had a look and the tables from https://www.hepdata.net/record/ins928289 match the data up to a factor of 1.0187 for all bins.

I have checked only Table 1 (which is the Z) against https://github.com/NNPDF/nnpdf/blob/master/nnpdf_data/nnpdf_data/commondata/ATLAS_Z0_7TEV_36PB/data_legacy_ETA.yaml
(there's also a factor 1000 of fb vs pb)

In cases like this, when there's one single factor for all bins, your best bet is to look at the old buildmaster and... indeed...

nnpdf/buildmaster/filters/ATLASZRAP36PB.cc

Line 24 in 843a03d

const double lcorr = 1.0187; // correction factor due to luminosity upgrade

[ecole41]

I am not sure if I should include this conversion factor here

[jacoterh]

looking at commondataparser.py this is valid input! So I would keep it.

[jacoterh]

@ecole41 if you could please redo the report including conversion_factor = 1.0187 it's easier to compare theory and data. Thanks.

[ecole41]

@ecole41 if you could please redo the report including conversion_factor = 1.0187 it's easier to compare theory and data. Thanks.

The report was made with the conversion factor in the metadata already, so it the old and new should hopefully match. I will remove the comment now

[jacoterh]

@ecole41 if you could please redo the report including conversion_factor = 1.0187 it's easier to compare theory and data. Thanks.

The report was made with the conversion factor in the metadata already, so it the old and new should hopefully match. I will remove the comment now

Ah interesting, is there a reason why the theory is consistently higher than the data then? I see it's the same in the old implementation, so it's technically not part of this PR, but I got curious.

[ecole41]

@ecole41 if you could please redo the report including conversion_factor = 1.0187 it's easier to compare theory and data. Thanks.

The report was made with the conversion factor in the metadata already, so it the old and new should hopefully match. I will remove the comment now

Ah interesting, is there a reason why the theory is consistently higher than the data then? I see it's the same in the old implementation, so it's technically not part of this PR, but I got curious.

Are we sure that the conversion factor should be included in the metadata? I have already included it when producing the data.yaml file so maybe it isn't needed in the metadata also? Then maybe the theory would be more consistent with the data

[jacoterh]

onversion factor should be included in the metadata? I have already included it when producing the data.yaml file so maybe it isn't needed in the metadat

Maybe, the best way here is to simply try what the theory vs data comparison looks like without including this factor, i.e. setting it to one.

[ecole41]

onversion factor should be included in the metadata? I have already included it when producing the data.yaml file so maybe it isn't needed in the metadat

Maybe, the best way here is to simply try what the theory vs data comparison looks like without including this factor, i.e. setting it to one.

Here is with conversion_factor: 1.0187: https://vp.nnpdf.science/6-mHiiJJTcC5Mf86u4NJ2g==/

Here is with conversion_factor: 1.0: https://vp.nnpdf.science/4JZ3wcPYTDOGHtDyu70pjg==/

There is a difference but I am not sure which one is correct. I would guess to keep the conversion factor equal to 1 as this has already been included in the data.yaml? But that might be wrong

[scarlehoff]

Hi @ecole41 this includes the correction we talked about on Wednesday and it can be merged right? (same for the Z 36PB PR)

[scarlehoff]

I'm a bit confused about this one. It seems the experimental uncertainties are much smaller. I think in the comparison you were always using the legacy variant, as you were using the old name instead of the new name.

In order to keep compatibility, whenever the new name is being used, it defaults to the legacy variant.

In any case, I believe the difference is coming from atlaslumi10 which in the new implementation is always a factor of 10 smaller. Could you check whether this is a bug (or whether the previous dataset was bugged and the luminosity was a factor of 10 too big).

Also, just in case, could you check also the datasets you already merged (if any). Since you were checking with the legacy names some small bugs could've passed unnoticed.

[scarlehoff]

Suggested change

	label: abs_eta
	label: r"|$\eta|$"

[ecole41]

I can see where the issue is, I have implemented the 3.5% lumi uncertainty incorrectly and inserted it as '0.35'. I will change this now and check the others also

[ecole41]

To produce reports using the new data (not the legacy), is it a case of just changing the dataset to the new dataset name? I think I remember that it was not working when I did this but I can try this again

[scarlehoff]

Yes. You need to use the new name (and then variant legacy will take the old data).

The reason why using the old name automatically selects the legacy is so that we can reproduce the old runcard that were using the old names (the mapping is in datasets_names.yml).

Let me know if it doesn't work, there might be some bug.

[ecole41]

When I change the name to the new dataset, I get this error:

/Users/ellacole/codes/nnpdf/nnpdfgit/nnpdf/validphys2/src/validphys/deltachi2.py:123: SyntaxWarning: invalid escape sequence '\c'
  label=f"{pdf.label} - $\chi^2_{0}$={total_chi2_data.central_result:.0f}",
[ERROR]: Bad configuration encountered:
Dataset ATLAS_WPWM_7TEV_36PB not found
Instead of 'ATLAS_WPWM_7TEV_36PB', did you mean one of the following?
 - ATLAS_WP_JET_8TEV_PT
 - ATLAS_WM_JET_8TEV_PT
 - ATLAS_2JET_7TEV_R06

[scarlehoff]

The complete name is ATLAS_WPWM_7TEV_36PB_ETA (<setname>_<observable_name>)

[ecole41]

Thank you, I have redone the compatibility checks and the old vs new report : https://vp.nnpdf.science/5lqgkuPJTleEVVvwvAZC_Q==/ using the new dataset name, and after changing the ATLASLUMI uncertainty to 3.5%. They look to match and the uncertainties match the old legacy uncertainties also