Implement v1 file format [WIP]

[t7phy]

Feature TODOs:

• Generalize Channel to support arbitrarily many PIDs. This is implemented with commits f32902a, 2417c92 and 03f2dc6.
• The structure Order should support a fragmentation scale. Started with commits 5e281ae and 02e48e9.
• The CLI should support varying this new fragmentation scale. We need the following point variations: 1 (no scale variation), 3 (vary all scales with the same factor), 7 and 9 (assuming that there's no fragmentation scale), and 17 and 27 (assuming there's a fragmentation scale)
• Extend the evolution code to take care of (at least) one, two and three convolutions with possibly one, two and three different EKOs
• Finally, we need new subgrid types that support possibly arbitrarily many scales and momentum fractions and which support filling or are optimized for space. We should use the PackedArray struct that we wrote some time ago.
• To fix the tests, we need import v0 PineAPPL grids and convert the subgrids into the new subgrid types.
• Add machine-readable MC results and uncertainties to calculate interpolation error #270

Code TODOs:

• Fill in all the TODO comments.
• Change types of members of Order to u8
• Generalize channel! to arbitrarily many PIDs
• Support arbitrarily many scales and fix import of flexible-scale fastNLO tables
• Test evolution for flexible-scale fastNLO tables
• Simplify bin treatment: remove BinInfo, and have instead fill limits (1d limits that only concern Grid::fill) and bin limits (n-dimensional limits)
• Add fragmentation scales to Grid::evolve_info
• Test EvolveInfo::frg1 and FkTable::frg0
• Make it possible to have different initial factorization and fragmentation scales in an FK-table
• Test different initial factorization and fragmentation scales in an FK-table
• Rename lagrange_subgrid
• Add support for static scale detection in previous subgrid type
• Rename PackedQ1X2SubgridV1
• Remove NodeValues
• Remove Mu2
• Implement D=N for general_tensor_mul in evolution.rs
• Test D=3 for general_tensor_mul in evolution.rs @Radonirinaunimi
• In Grid::merge check if grids are compatible with each other before merging
• Cleanup code

CAPI TODO:

• increase code coverage
• unbreak GridOptFlags (see commit 54a59f3)
• rename pineappl_channel_* to pineappl_channels_*?
• check generated grids of new example programs
• rename -v1.cpp suffix of example programs to .cpp and rename the previous example programs from .cpp to -deprecated.cpp. This should clarify that the use of v0 functions is deprecated (but still works!)

Fortran module TODO:

• add new functions

Python API:

• update to pyo3-0.22.5, this possible now since numpy-0.22.0 was released. Figure out what new features we can leverage from 0.22.x (see its CHANGELOG):
  • numpy-2 support (works out of the box)
  • declarative modules and submodules
  • Python 3.13
  • recheck whether we still need #![allow(unsafe_op_in_unsafe_fn)]
• Update tutorials
• raise minimum required Python version to 3.7 in pyproject.toml

[cschwan]

I believe the list shown in #118 is probably a bit too ambitious for this pull request. Realistically, we should implement all the items listed in #172.

[cschwan]

@Radonirinaunimi and @janw20: could one of you take care of the new item "check generated grids of new example programs"? I believe I once did that unsuccessfully, so possibly there's a bug somewhere. The easiest way would be to always use the v1 grid in the remaining C++ examples. (I forgot to use a PDF set with a non-zero photon PDF). I believe that right now the generated grid isn't checked anywhere.

[Radonirinaunimi]

@Radonirinaunimi and @janw20: could one of you take care of the new item "check generated grids of new example programs"?

Sorry @cschwan for the very late reply, I was away for a while. Yes, I will check while I am finishing the CAPI TODO.

[Radonirinaunimi]

For the record, the Python installation failed with maturin v1.8.0 because of this PR PyO3/maturin#2391. But simply adding dynamic = ["version"] to pyproject.toml solved the issue (this shouldn't have any effect when packaging to PyPI).

[cschwan]

Great 👍, thank you @Radonirinaunimi! Are all the grids that are being generated by the examples also being convolved? If that's the case you can also tick the corresponding checkbox.

[cschwan]

For the record, the Python installation failed with maturin v1.8.0 because of this PR PyO3/maturin#2391. But simply adding dynamic = ["version"] to pyproject.toml solved the issue (this shouldn't have any effect when packaging to PyPI).

Since no one of us knew this, we could document that this is a requirement. Our requirement is that we want version numbers only in Cargo.toml files and therefore all other version numbers must be dynamically derived; I found this link: https://packaging.python.org/en/latest/guides/writing-pyproject-toml/#static-vs-dynamic-metadata.

[Radonirinaunimi]

Happy new year all!

Great 👍, thank you @Radonirinaunimi! Are all the grids that are being generated by the examples also being convolved? If that's the case you can also tick the corresponding checkbox.

This is now the case. There is only one item left to fully finish the C API part.

Since no one of us knew this, we could document that this is a requirement. Our requirement is that we want version numbers only in Cargo.toml files and therefore all other version numbers must be dynamically derived; I found this link: https://packaging.python.org/en/latest/guides/writing-pyproject-toml/#static-vs-dynamic-metadata.

Yes, we definitely should document this.