Upgrade to PineAPPL v1

[Radonirinaunimi]

This PR tests the new Python interface of the upcoming PineAPPL v1. There are a few notable changes affecting pineko directly:

• The types of convolutions (be it for grids or FK tables) are accessed through the convolutions attributes. These information are no longer determined from the metadata (address the shortcomings discussed in Bump pineappl version nnpdf#2129 (comment) and Allow evolution and convolution with different ekos for a single grid  #181 (comment)).
• Grids can be evolved with an arbitrary number of EKOs (no longer limited to two operators). This removes the need for operator1 and operator2 in favor of just operators.
• Grids and FK tables can be convolved with an arbitrary number of PDFs (no longer limited to two PDFs). Similarly, this removes the need for pdf1 and pdf2 in favor of pdfs.
• Add a new variation of scale - which is the fragmentation scale xia.

The only remaining thing for which we will still require an ad-hoc hack/tweak is the checks that the PDFs are ordered according to the type of convolutions. This is an LHAPDF problem so there isn't much that we can do.

This will deprecate #192.

Remaining to do:

• profile the computation of the Jet EKOs

[cschwan]

When this is working I suggest you also try to implement #183 - this should decrease the time and space needed to perform an evolution. Also the required changes should be minimal.

[Radonirinaunimi]

When this is working I suggest you also try to implement #183 - this should decrease the time and space needed to perform an evolution. Also the required changes should be minimal.

Thanks for letting me know about this! I will surely do once this is working indeed.

[giacomomagni]

Looks great to me. Some really minor comments:

• Just a small question: why key_values are still around and now we don't have just metadata ? Why the theory card is still saved to key_values ?

pineko/src/pineko/scale_variations.py

Lines 238 to 240 in e8d7282

	# propagate metadata
	for k, v in ori_grid.key_values.items():
	new_grid.set_key_value(k, v)

• I did not check, I'm able to produce a real FKtable myself.

[cschwan]

Looks great to me. Some really minor comments:

* Just a small question: why `key_values` are still around and now we don't have just metadata ? Why the theory card is still saved to `key_values` ?

Indeed, it should be {set_,}metadata instead of {set_,}key_value. I'm not why it still works the old way.

[Radonirinaunimi]

Thanks a lot @giacomomagni for the review! I will address them once I am in front of a computer this afternoon.

Looks great to me. Some really minor comments:

* Just a small question: why `key_values` are still around and now we don't have just metadata ? Why the theory card is still saved to `key_values` ?

Indeed, it should be {set_,}metadata instead of {set_,}key_value. I'm not why it still works the old way.

Some of these set_key_values are redefinitions coming from FakeObject classes in the tests and hence why still work (and also why I didn't catch them). I will replace these when addressing the reviews.

[giacomomagni]

As long as it works it's good for me!

[Radonirinaunimi]

As long as it works it's good for me!

Perfect, thanks! Let's wait for #215 and we can test it here.

[Radonirinaunimi]

Everything here is now done! The only thing missing here is the stable version of PineAPPL; as soon as that is available we can bump the version here and merge.

[scarlehoff]

I'm currently using this branch and seems to work well :). The only problem I've found up to now is what I already reported when there are empty bins.

[scarlehoff]

Hi @Radonirinaunimi one request before merging this (and I think it is better to do it here since it changes in 1.0), could we ensure that all metadata from the original grid is propagated to the fktable?

[Radonirinaunimi]

Hi @Radonirinaunimi one request before merging this (and I think it is better to do it here since it changes in 1.0), could we ensure that all metadata from the original grid is propagated to the fktable?

Yes! In principle this should be the case but I will explicitly double-check.

[scarlehoff]

Great!

(just to say, I didn't check it wasn't the case, I was looking at the changes and realized that in the scale_variations.py the propagation is explicit but I couldn't find in the evolve, but perhaps I just missed it, too many changes)

[Radonirinaunimi]

Hi @Radonirinaunimi one request before merging this (and I think it is better to do it here since it changes in 1.0), could we ensure that all metadata from the original grid is propagated to the fktable?

Sorry, I missed to reply to this earlier. The metadata are always automatically propagated into the FK tables. Scale varied grids/FK tables are created from new instances so that's why it is needed to manually copy the metadata.

[felixhekhorn]

I didn't read the big evolve.py and theory.py (yet), but I found a stupid typo