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.

Hi, I completed the Fortran interface. I made some (minor) design decisions that I would like your opinion on:

• Since Kinematics is an enum with tuple-like variants, it is converted to a C struct holding a tag variable and a C union. Fortran doesn't support unions, so I use a Fortran derived type (pineappl_kinematics) that also has a tag variable, but only one integer variable for the index instead of the C union. I found this to be the cleanest solution, or do you have a better idea?
• For some reason, Fortran cannot do arrays of procedure pointers, so I created a new derived type for the PDF and alpha_s functions, pineappl_xfx and pineappl_alphas, that each holds the procedure pointer as a member named proc. This is needed so that an array of PDF functions can be passed to pineappl_grid_convolve. For consistency, I also changed this in pineappl_grid_convolve_with_one and pineappl_grid_convolve_with_two. This goes against keeping backward compatibility with the 0.x of Pineappl versions, but until there is a solution to Investigate if we can compile/install the Fortran module #257, I figured that the user would make their own copy of pineappl.f90 anyway and use that, so backward compatibility is not that important in the Fortran case.

I also noticed two small bugs in the v1 C++ examples which I fixed in my first commit. Related to that: Is there a reason why pineappl_grid_new creates the kinematics in the order (Q², x₁, x₂), and not (x₁, x₂, Q²), as was always the order in, e.g., pineappl_grid_fill? I think this might have been the reason for the bug in examples/cpp/fill-grid-v1.cpp line 113

Hi @janw20, thanks a lot for completing the Fortran interface!

Hi, I completed the Fortran interface. I made some (minor) design decisions that I would like your opinion on:

* Since `Kinematics` is an enum with tuple-like variants, it is converted to a C struct holding a tag variable and a C union. Fortran doesn't support unions, so I use a Fortran derived type (`pineappl_kinematics`) that also has a tag variable, but only one integer variable for the index instead of the C union. I found this to be the cleanest solution, or do you have a better idea?

* For some reason, Fortran cannot do arrays of procedure pointers, so I created a new derived type for the PDF and alpha_s functions, `pineappl_xfx` and `pineappl_alphas`, that each holds the procedure pointer as a member named `proc`. This is needed so that an array of PDF functions can be passed to `pineappl_grid_convolve`. For consistency, I also changed this in `pineappl_grid_convolve_with_one` and `pineappl_grid_convolve_with_two`. This goes against keeping backward compatibility with the 0.x of Pineappl versions, but until there is a solution to [Investigate if we can compile/install the Fortran module #257](https://github.com/NNPDF/pineappl/issues/257), I figured that the user would make their own copy of `pineappl.f90` anyway and use that, so backward compatibility is not that important in the Fortran case.

I had a look at it and it looks good. I don't think there is a cleanest a more robust to approach this apart from what is being done now (actually, this was how I also envisioned how it'd look like).

I also noticed two small bugs in the v1 C++ examples which I fixed in my first commit.

Thanks for spotting and fixing this bug! I had this under my radar before but somehow forgot to fix it (maybe I remembered to only do so on the Python API).

Related to that: Is there a reason why pineappl_grid_new creates the kinematics in the order (Q², x₁, x₂), and not (x₁, x₂, Q²), as was always the order in, e.g., pineappl_grid_fill? I think this might have been the reason for the bug in examples/cpp/fill-grid-v1.cpp line 113

I don't think there is a real reason why the kinematics have to be ordered in such a way. The restriction is coming from these lines:

Just for the record, the panicking of the Fortran v1 examples could be resolved by explicitly declaring the constants given to pineappl_interp_tuples as double precision (i.e., suffixing them with _dp):

Without this, applgrid::fx2 didn't converge for higher y values, which resulted in a panic when reaching unreachable!().

Thanks again @janw20 for fixing this issue! I still don't understand why this was only (?) happening on Arch, but I guess this doesn't matter anymore as the solution works perfectly.

@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 believe that right now the generated grid isn't checked anywhere.