kkumer / gepard Goto Github PK

... and cannot change variables in local scope. See here. This means nontrivial rewriting of some code before transition to Python 3 becomes possible.

When running on MS Windows, I get

Warning (from warnings module):
  File [...]\Python310\site-packages\gepard\evolution.py", line 270
    tginv = ephnd/np.tan(np.pi*znd/2)
RuntimeWarning: overflow encountered in tan

And three other tan overflows in other places, all related to MSBAR non-diagonal evolution.
Number obtained at the end looks all right, though. No such error on Linux.

val + gauss(0, err) might not be correct choice. Think about it ...
Fitter.py:205

Calculation of given CFF is done by activating a net, which calculates all CFFs, and then disposing of all CFFs apart from the needed one. This is then repeated for each needed CFF. This makes everything slower by a factor of 5-10.

CFFs that are not trained but are calculated from other CFFs (like in dispersion relations approach or flavor decomposition) still must be present as nodes in output layer. This probably doesn't lead to any errors, but is confusing and unclean coding.

Some tests slightly failing for unknown reasons. Nothing show-stopping:

1. test_fit2 8.139 != 8.489. This is found to be due to pyminuit --> iminuit change (tests passes on initial release of py2 branch, and then fails like above after commenting out pyminuit import.) It is not clear why other fits are not affected by this package change. We should just go to iminuit and not worry about this one.

2. ntgl2 DVEMNLO_test.py:test_gepardTFFsNLO 0.54106 != 0.53283. Same for py2 and py3.

google groups .. SE.

It looks like py3 shelve dropped support for Berkeley DB.

Namely, while unpickling, __setitem_ is called before __init__ or __setstate__ and then self.d1 is still undefined. To resolve, see here but it may involve another one-time transcoding of database in python2 code.

[Errno 11] Resource temporarily unavailable occurs often. This could be fixed by introducing some locks.

nosetests refuse to capture logzero messages.
--loging-level is totally ignored.
--logging-clear-handlers helps but is not perfect