Fix NaN appearing in heavy N3LO grids#346
Conversation
|
For the record, using 1924917, here are the numbers comparing with |
ehm this is hard to read - can't you please do |
This was my first plan but the grids live on different computers... xd But I can do so later. |
|
Ok, I just updated #346 (comment). |
thanks! I am surprised the grids differ so much at LO (where they should be bit-by-bit identical, since there is no integration) - else I think we are very happy with this ... |
|
Well, the difference is of the order of I will also re-compute the fiatlux grids and then I think we are done with this. |
Co-authored-by: Felix Hekhorn <felixhekhorn@users.noreply.github.com>
|
Closed in favor of #347 ! |
The following exposes the issues that plague N3LO heavy grids with
NaN. 9e4f55a provides a simple fix but might not be exactly what we wnat. There were mainly two problems working together.Problem 1: NaN values in N3LO heavy quark grid files
The pre-computed N3LO coefficient function grids in src/yadism/coefficient_functions/heavy/n3lo/grids/ contain
NaNvalues. The problem is that whenRectBivariateSplineheavy/n3lo/__init__.py is constructed from a grid containingNaNvalues, the spline fitting algorithm could propagate theNaNvalues through the entire set of spline coefficients.NaNusing nearest neighbor fit.Problem 2:
replace_nans_with_0never run on generic/compound observablesThe safety net (
replace_nans_with_0) which was meant to safeguard this in the first place never gets called for generic observables (which in the case for NMC isF2_total).