Issue when converting PineAPPL to APPLgrid

[fgiuli]

Hi,
I tried to convert the grids from ATLAS 7 TeV W,Z measurement (arXiv:1612.03016) using the pineapple export command.
The grids are the ones available on Ploughshare: https://ploughshare.web.cern.ch/ploughshare/

I didn’t have any trouble when converting the Z 7 TeV grids, but when converting the W ones, I got the following error:

thread main panicked at pineappl_cli/src/export/[applgrid.rs:138](http://applgrid.rs:138/):29:
assertion failed: (left approx_eq right)
   left: 0.05130225,
   right: 1.0
stack backtrace:
   0:     0x55cec67e9a99 - <std::sys::backtrace::BacktraceLock::print::DisplayBacktrace as core::fmt::Display>::fmt::hc002032c745ec399
   1:     0x55cec650d0cb - core::fmt::write::h78425ec9962d4be7
   2:     0x55cec67b16c2 - std::io::Write::write_fmt::ha00b146e89c56092
   3:     0x55cec67eb012 - std::sys::backtrace::BacktraceLock::print::h59ceb186f016850e
   4:     0x55cec67eae7b - std::panicking::default_hook::{{closure}}::h9fcfa010b5ecd19c
   5:     0x55cec67eb55a - std::panicking::rust_panic_with_hook::h0a4b940661a26423
   6:     0x55cec67eb105 - std::panicking::begin_panic_handler::{{closure}}::h72160a9fdca8fdc8
   7:     0x55cec67eb069 - std::sys::backtrace::__rust_end_short_backtrace::hb6826ea75cd9c94b
   8:     0x55cec67eb054 - rust_begin_unwind
   9:     0x55cec650be52 - core::panicking::panic_fmt::h47b5abafd035aaaa
  10:     0x55cec661cc77 - core::iter::adapters::flatten::and_then_or_clear::h5f2ece5d2df98a73
  11:     0x55cec661bed1 - <core::iter::adapters::chain::Chain<A,B> as core::iter::traits::iterator::Iterator>::next::hdeda939158cbd85e
  12:     0x55cec6616ba8 - pineappl_cli::export::applgrid::convert_into_applgrid::h8971fbe3cbd44c1d
  13:     0x55cec64bf9e2 - pineappl::main::h2431e51d99007086
  14:     0x55cec64af543 - std::sys::backtrace::__rust_begin_short_backtrace::h577825aa252501e5
  15:     0x55cec64c8202 - main
  16:     0x7fceb64295d0 - __libc_start_call_main
  17:     0x7fceb6429680 - __libc_start_main@GLIBC_2.2.5
  18:     0x55cec64ac3ea - _start
  19:                0x0 - <unknown>

Have you ever seen such an error?

The command line I used is the following one:

pineappl export pinejet-atlas-wm-arxiv-1612.03016/grids/pinejet-atlas-wm-arxiv-1612.03016-xsec000.lz4 wm_etay.appl MSHT20nnlo_as118

To install the pineapple CLI, I followed the instructions described here: https://github.com/NNPDF/pineappl/blob/master/docs/installation.md

Thanks a lot in advance for your time and help.

Best,
Fra

[felixhekhorn]

Ciao @fgiuli , I think you got hit by this:

pineappl/pineappl_cli/src/export/applgrid.rs

Lines 136 to 138 in c44def4

	// TODO: if the factors aren't trivial, we have to find some other way
	// to propagate them
	assert_approx_eq!(f64, factor, 1.0, ulps = 4);

because

$ pineappl read --channels pinejet-atlas-wm-arxiv-1612.03016-xsec000.lz4 
c          entry                     entry                         entry                     entry            entry        entry        entry        entry        entry        entry
--+---------------------+-----------------------------+-----------------------------+---------------------+------------+------------+------------+------------+------------+------------
0  0.05130225 × ( 1, -4) 0.9493557302137656 × ( 1, -2) 0.9493557302137656 × ( 3, -4) 0.05130225 × ( 3, -2)                                                                  
1  1 × ( 1, 21)          1 × ( 3, 21)                                                                                                                                       
2  1 × (21, -4)          1 × (21, -2)
[...]

i.e. the LO channel d-ubar etc. does not have a trivial coupling, but (if I guess correctly) the CKM matrix elements. As per the snippet above this is currently not supported by the exporter. This is not the case for Z, which is the reason why it works:

$ pineappl read --channels pinejet-atlas-z0-arxiv-1612.03016-xsec000.lz4 
c     entry        entry        entry        entry        entry        entry        entry        entry        entry
--+------------+------------+------------+------------+------------+------------+------------+------------+------------
0  1 × ( 1, -1) 1 × ( 3, -3) 1 × ( 5, -5)                                                                  
1  1 × ( 2, -2) 1 × ( 4, -4)                  
[...]

In order two resolve this, we would need two features:

1. the possibility to split a given channel into it's subparts, i.e. make d-ubar independent from d-cbar etc. - and I'm not sure if we have that feature yet. We will need help from others (@Radonirinaunimi @cschwan ) to answer that question
2. the possibility to move the prefactors = CKM matrix elements into the actual grids - this functionality is actually provided by this PR Add Grid::merge_channel_factors and Channel::factor #353

[scarlehoff]

the possibility to split a given channel into it's subparts, i.e. make d-ubar independent from d-cbar etc. - and I'm not sure if we have that feature yet. We will need help from others (@Radonirinaunimi @cschwan ) to answer that question

This exists, --split-channels, then you need to re-scale each single channel by the value of the CKM, then redefine the channel so the factor is 1.0.

Basically the script would look something like

write --split-channels splitted_grid.lz4
do per each channel with a pre-factor:
       write --delete-channels (delete all channels but one) --scale (scale the remaining grid by the prefactor) -> flavour_{i}.lz4
write --delete-channels (delete all channels for which we have a flavour_{i}.lz4 grid) -> umodified_channels.lz4
merge all flavour_i with unmodified_channels

And you would need to redo that for every W grid. If your pain threshold is high enough you can automatize some of it with awk.

I think the right solution is indeed #353 (but more to the point, it should be done automatically by the export)

[cschwan]

Hi @fgiuli,

Thank you for reporting this!

As @felixhekhorn and @scarlehoff already hinted at, this is due to a feature difference between APPLgrid and PineAPPL; the former doesn't support factoring out what in this case are, I believe, squared CKM matrix elements. With this feature the PineAPPL grids are a bit smaller because we have fewer channels. In the exporter we have to take care of the feature difference, and when the exporter was implemented I apparently was too lazy 😄 to actually do it.

With #253 this should indeed be easily doable in the exporter automatically, and I plan to have this done within the next few days. If you're in a rush, you can indeed try @scarlehoff's recipe, although that will be a bit tedious. Let us know if you need support!

[fgiuli]

Dear all,
thanks a lot for this. @cschwan I can wait few days, let me know when this is fixed.

Best,
Fra

[jamspandex]

I am not actually sure I understand the discussion, since in applgrid it is possible to store as many, or as few separate parton-parton luminosities as you wish, even to the point of having duplicate terms, such that you can have eg multiple separate d-cbar contributions if you so wished, in case you wanted different internal diagrams to the matrix elements
connected to the input partons, that you wanted to treat differently, so you would not need to group eg all d-cbar processes into a single contribution in the lumipdf instance. Of course, when performing the convolution then a c-dbar colliding pair would then of course affect both the c-dbar contributions. One of the objectives of implementing like this was in case people wanted to allow the CKM matrix to be changed a-posteriori, since in the case of NNLO production with say a gg input pair, terms which included a weak interaction with a different ckm term from some other gg weak interaction could be stored in a seperate gg parton-parton luminosity. However, it was never fully developed as there was no demand for it at the time, but the code was implemented such that it would be staightforward to modify to achieve this in the future if there were any requests for it, but we never received any.

[cschwan]

Maybe I misrepresented what APPLgrid can and cannot do, and in that case I'm of course happy to convert the grids one-to-one.

To explain it better, let's look the example that's actually the problem here, pp -> W+. At LO there are four partonic channels:

• ud~ -> W+
• cs~ -> W+ and the more suppressed partonic channels
• us~ -> W+ and
• cd~ -> W+.

At LO their matrix elements are the same, except of course the CKM factor. To keep the size of a Grid as small as possible, we'd like to group as many partonic channels together. In the code we therefore define a Channel (should be a lumi_pdf in APPLgrid) as follows,

|V_{ud}|^2 (u, d~) + |V_{cs}|^2 (c, s~) + |V_{us}|^2 (u, s~) + |V_{cd}|^2 (c, d~)

where u, d~ stand for the PDFs of the corresponding partons and |V_{ud}|^2 are the factors. You can see this definition as channel #0 in @felixhekhorn's answer, where the factors are printed with their numerical values and the PDFs are represented by their parton PDG values:

$ pineappl read --channels pinejet-atlas-wm-arxiv-1612.03016-xsec000.lz4 
c          entry                     entry                         entry                     entry            entry        entry        entry        entry        entry        entry
--+---------------------+-----------------------------+-----------------------------+---------------------+------------+------------+------------+------------+------------+------------
0  0.05130225 × ( 1, -4) 0.9493557302137656 × ( 1, -2) 0.9493557302137656 × ( 3, -4) 0.05130225 × ( 3, -2)                                                                  
1  1 × ( 1, 21)          1 × ( 3, 21)                                                                                                                                       
2  1 × (21, -4)          1 × (21, -2)
[...]

So my question is: can lumi_pdf save these factors (0.05130225, ...) in a similar way, @jamspandex?

[cschwan]

Hi @fgiuli, can you please try the latest version from master? I believe the bug should have been fixed.

[fgiuli]

Ciao @cschwan,

maybe I am doing something wrong BUT the error is still there:

[giuli@pplxint13 xFitter_EL9]$ pineappl export pinejet-atlas-wm-arxiv-1612.03016/grids/pinejet-atlas-wm-arxiv-1612.03016-xsec000.lz4 Wm_etay.appl MSHT20nnlo_as118
thread main panicked at /home/giuli/.cargo/registry/src/index.crates.io-6f17d22bba15001f/pineappl_cli-1.0.0/src/export/applgrid.rs:138:29:
assertion failed: (left approx_eq right)
left: 0.05130225,
right: 1.0

Below you can find the various steps I followed:

git clone https://github.com/NNPDF/pineappl.git
cd pineappl
APPL_IGRID_DIR=/data/atlas/atlasdata/giuli/xFitter_EL9/deps/applgrid-1.6.36/src/ cargo install --locked --features=applgrid --force pineappl_cli
export PATH=/home/giuli/.cargo/bin:$PATH

Cheers,
Fra

[cschwan]

Ciao @fgiuli,

I know what went wrong: cargo install downloads the published version of the CLI from crates.io and ignores your cloned repository. Instead, add --git https://github.com/NNPDF/pineappl.git to the cargo command; you can leave out the preceding git clone call and can run cargo from any directory.

See also the 'Development version' section of the installation manual: https://nnpdf.github.io/pineappl/docs/installation.html#alternative-development-version.

[fgiuli]

Thanks @cschwan indeed this solved the issue, and I was able to perform the export into APPLgrid.

Cheers,
Fra

[cschwan]

Great 👍, in that case I'll close this Issue. If there more problems just open a new one.