Fix pure Fragmentation scale evolution#398
Conversation
Radonirinaunimi
changed the title
There was a problem hiding this comment.
I believe the TODO comment,
// TODO: implement evolution for non-zero fragmentation scalessignifies that any evolution with fragmentation function hasn't been tested yet. Is that the case and is you testing SIA just the first instance of finding something wrong?
| /// Note: for pure time-like (FF) grids, PineAPPL stores only fragmentation scales. In that | ||
| /// case, this getter returns `frg1` as a backwards-compatible fallback. | ||
| #[getter] | ||
| fn fac1<'py>(&self, py: Python<'py>) -> Bound<'py, PyArray1<f64>> { |
There was a problem hiding this comment.
This change will result in the Python and Rust APIs behaving differently. Is this justified?
There was a problem hiding this comment.
Yes, I'd say that this is justified given how minimal this change is compared to say accounting it at the level of say pineko which would introduce non-negligible breaking changes.
The comment indeed mentions that we FF scale evolution has not been tested at all. The reason was that until now we did not really grids and evolution operators to really test it. Now that we have PineAPFEL, we can easily test this for not only SIA but also for SIDIS, etc. The issue originally manifested from SIA but noticed it also for SIDIS. And this PR solves both. |
2 participants
Sorry for having been slow lately which has resulted in #394 being blocked. In the meantime, I stumbled upon an issue that has to do with evolving pure FF grids, ie with
fac = NoScaleand only fragmentation scale involved. This PR provides a fix for this and adds a test.