LHA SV fails for smallest x in CI

[felixhekhorn]

we still have the 100% error in github:

Computing for theory=45286e9, ocard=cc12964 and pdf=ToyLH ...
Compute external result

Log added, hash=2e5273d953ef355a2f48badae3729333e94e6808ae941048e2e2e943771b0e63


 ─── 
  S  
 ─── 
               x       Q2         eko     eko_error         LHA  percent_error
0   1.000000e-07  10000.0    0.000000  0.000000e+00  251.422304    -100.000000
1   1.000000e-06  10000.0  132.769958  1.641839e-04  133.133286      -0.272906

but I cannot reproduce this locally

In [2]: dfl(-1)
Out[2]: 

- theory: `45286e92f0fbedc3ed4a84b47547190efc4bde84583e5782716a5c5c70448aed`
- obs: `8beae75234d8ba49de7079e5f76d3916dd810708d31bb54f85505faf1c470055`
- using PDF: *ToyLH*

S
               x       Q2         eko     eko_error         LHA  percent_error
0   1.000000e-07  10000.0  250.741696  3.320808e-04  251.422304      -0.270703
1   1.000000e-06  10000.0  132.769958  1.641844e-04  133.133286      -0.272906

Note that the obs hash is not the same ... I seem to remember to have seen this before ... @giacomomagni ? or @t7phy ?

Originally posted by @felixhekhorn in #238 (comment)

[giacomomagni]

Having rerun this locally after recompiling everything from scratch, I confirm I'm not able to reproduce the error.

[felixhekhorn]

@giacomomagni can you confirm my obs hash?

[giacomomagni]

I now have:

In [6]: dfl("b8b91c")
Out[6]: 

- theory: `45286e92f0fbedc3ed4a84b47547190efc4bde84583e5782716a5c5c70448aed`
- obs: `5d279b7c4222fc5f9b2858f7438e69a683a0030ea3a41c1093be921e2ae0f25b`
- using PDF: *ToyLH*

S
               x       Q2         eko     eko_error         LHA  percent_error
0   1.000000e-07  10000.0  250.741696  3.320783e-04  251.422304      -0.270703
1   1.000000e-06  10000.0  132.769958  1.641842e-04  133.133286      -0.272906
2   1.000000e-05  10000.0   65.332846  9.408269e-05   65.492394      -0.243614
3   1.000000e-04  10000.0   29.348630  6.430424e-05   29.415030      -0.225732

So theory hash is the same as in here, but obs is different from both of you...

EDIT: Note that ls(o) is currently broken:

OperationalError: (sqlite3.OperationalError) no such column: operators.interpolation_xgrid
[SQL: SELECT operators.uid AS operators_uid, operators.hash AS operators_hash, operators.ctime AS operators_ctime, operators.mtime AS operators_mtime, operators.atime AS operators_atime, operators.interpolation_is_log AS operators_interpolation_is_log, operators.interpolation_polynomial_degree AS operators_interpolation_polynomial_degree, operators.interpolation_xgrid AS operators_interpolation_xgrid, operators.debug_skip_non_singlet AS operators_debug_skip_non_singlet, operators.debug_skip_singlet AS operators_debug_skip_singlet, operators.ev_op_max_order AS operators_ev_op_max_order, operators.ev_op_iterations AS operators_ev_op_iterations, operators.mugrid AS operators_mugrid, operators.backward_inversion AS operators_backward_inversion, operators.polarized AS operators_polarized, operators.time_like AS operators_time_like 
FROM operators]
(Background on this error at: https://sqlalche.me/e/14/e3q8)

Most likely due to some refactor

[felixhekhorn]

EDIT: Note that ls(o) is currently broken:

I think this should have been fixed in #231 - and indeed I can not reproduce it. Can you check if you regenerate the DB it works also for you? (backup the old if you do not want to loose it - maybe a simple rename there can save you)

[felixhekhorn]

but obs is different from both of you...

now, this is strange ... I wonder if there is some platform dependency (on floats?)? moreover, the visible digits match exactly - between the two of us starting from the first point and with the CI after that ... actually, we do not agree on the error, although I think we should ... (quad is fully deterministic)

[giacomomagni]

I think this should have been fixed in #231 - and indeed I can not reproduce it. Can you check if you regenerate the DB it works also for you? (backup the old if you do not want to loose it - maybe a simple rename there can save you)

Oh yes true I still had an old db, now it works.
Maybe that can explain also the hash difference. Let me run again.

[giacomomagni]

The obs hash is still different from yours

[felixhekhorn]

The actual problem discussed here has been resolved see https://github.com/NNPDF/eko/actions/runs/4948469063/jobs/8849225663 . For the new problem of non-comparable hashes I opened #267