Channel manipulation in grids

[alecandido]

We should expose in the Python interface a function to manipulate luminosity function (in the first place, we need such a function in the Rust library).

Of course complicate manipulation are useless, but I would add a couple of simple ones:

• drop a lumi channel
• duplicate a lumi channel

Both of them should not involve generating further subgrids (but possibly dropping them), since the luminosity function can already optimize for equal channels. So, they are mostly about manipulating the luminosity function itself, rather than subgrids.

Even before, I will:

• expose the Grid.lumi in the Python interface.

[alecandido]

• expose the Grid.lumi in the Python interface.

Ok, this was simple. Done in 5f4902f.

[cschwan]

This will probably not do what you'd like: it only returns the first flavour combination, but discards the remaining flavour combinations and factors.

[alecandido]

This will probably not do what you'd like: it only returns the first flavour combination, but discards the remaining flavour combinations and factors.

I didn't understand...

The function I put above is just to query which is the luminosity function of the given grid. It is just a read function, not one for manipulating...

[cschwan]

This line:

5f4902f#diff-1f7e3cc6363a7e6cbf795dc23874cf1e6c5d09b5b254ce0c8710e389f2f6badaR593

will return uu~ if your lumi entry is 2 * uu~ + 1 * cc~. You're probably thinking of FkTable which has the limitation that all lumis are trivial, but that limitation doesn't exist for Grid.

[alecandido]

Ops, you're right...

Just copied from here:
https://github.com/N3PDF/pineappl/blob/5f4902f6e665c7f1734353376abb46db9216ad16/pineappl/src/fk_table.rs#L202
and I didn't notice the zero.

But you're right of course, let me iterate even on that dimension.

[alecandido]

I just tested on a DIS grid, and even there it was working, but because in yadism we're always writing trivial lumis...

[cschwan]

Madgraph5 doesn't and usually they're very non-trivial because we assume a diagonal CKM matrix.

[alecandido]

@cschwan check if now is more sensible (I checked is compiling and working, but again, on DIS; I'm going to check right now on TEST_RUN_SH)

[cschwan]

That looks much better, but you're still throwing away the factors; without them the lumis are incomplete!

[alecandido]

I had another try :)

[cschwan]

See also #165, this would simplify any querying/manipulation of the lumi function.

[alecandido]

• duplicate a lumi channel

I don't remember any longer why this would have been useful...

I still would like to be able to drop lumi channels (and consequently associated subgrids), and manipulate existing ones (i.e. manipulate/replace the content of a LumiEntry).
But for sure, what I don't want to do is to create additional channels, since there would be no subgrid associated, or I should copy all the existing subgrids associated to another channel.

[cschwan]

During the implementation of #199 I noticed that it's useful to have the following type of operation (and that should explain the question in #149 (comment)):

• Grid::transform_lumi: this operation converts a grid with n lumis into a grid with m new lumis, each having to be explicitly given to the function. The subgrids in the new grid are simply copies of the old subgrids specified by an index, and an additional factor allows to optionally rescale the new subgrids. That means this function accepts a Vec or a slice of tuples of the form (LumiEntry, usize, f64).

This allows to implement the following operations:

• split_lumi_entries: imagine we have Drell-Yan grid which has the lumi function

  1 x (2, -1) + 1 x (4, -3)
  

  If we'd like to calculate the size of the up-anti-down channel and charm-anti-strange channel separately instead of together, we'd have to run

  grid.transform_lumi(vec![(lumi_entry![2, -1, 1.0], 0, 1.0), (lumi_entry![4, -3, 1.0], 0, 1.0)])
  

  This will change the grid to have two lumi entries,

  1 x (2, -1)
  1 x (4, -3)
  

  whose corresponding subgrids are copies of the old subgrid with index 0 and that are scaled with the factor 1.0 (nothing happens). Now the two channel are separate and we can use pineappl channels to figure out their size.
• we can use a variation of split_lumi_entries with Grid::optimize_lumi to produce a luminosity function that resembles what's needed in Redefine channels such that the number of non-zero subgrids is minimal #199. We split up each LumiEntry into smaller pieces that either have complete overlap with all other split up lumis or no overlap. That, after optimizing the lumi function, will yield a new lumi function function with no overlaps sharing the largest number of channels together to keep the number of non-zero subgrids small.
• split_symmetric: this should for instance split 1 x (2, -2) + 1 x (4, -4) + 1 x (-4, 4) + 1 x (-2, 2) into two lumis, one being 1 x (2, -2) + 1 x (4, -4) and 1 x (-4, 4) + 1 x (-2, 2), which differ by transposing their partons. This is useful for Redefine channels such that the number of non-zero subgrids is minimal #199, which doesn't optimize the grid but it simplifies the channels: the lumis are getting shorter.

[cschwan]

Another operation that we'll need is to change the factors of the luminosity function if we'd like to change the values of the CKM matrix, for instance.

[cschwan]

Another operation that we'll need is to change the factors of the luminosity function if we'd like to change the values of the CKM matrix, for instance.

This can be done with with the Grid::set_lumis method and the CLI's write --rewrite-channels. This gist shows an application of it.

[cschwan]

In meantime we have quite a few operations on channels:

• Grid::split_channels
• Grid::delete_channels
• Grid::dedup_channels

and also the general-purpose access methods:

• Grid::channels
• Grid::channels_mut

which allow to change the channels arbitrarily. I'm closing this Issue, if more methods are required, please open a new Issue.