Update the calls to axes to evolve_info

[scarlehoff]

Closes #72

If I understood evolve_info correctly this should be doing the same as was done before. The only thing that I'm not sure about is what is the implicit masking that axes was doing? Or maybe axes assumed that all orders had the exact same x/q structure?

[cschwan]

@scarlehoff the old behaviour is to use all orders (mask set to all true), which potentially makes the EKOs larger than needed. That's not wrong just less performant.

[cschwan]

Superficially this looks good to me. However, I suppose you to test it if you haven't done it to make sure the order treatment is correct.

[scarlehoff]

For now I've tested that it works with merged grids. I'll test it with a random fktables from the NLO and NNLO theories that @andreab1997 has in dom.

[andreab1997]

Seems good even if in #75 is done in a different way

[alecandido]

Do not ask for a maximum value, just create a trivial mask

[alecandido]

Improvements (i.e. simplifications) postponed to #85. The rest looks perfect to me :)

[scarlehoff]

In order to test this I'm redoing all fktables in theory 400.

DIS agree perfectly with what @andreab1997 has in dom for theories 4054 (NLO) and 4244 (NNLO).
ATLAS FKTables have already finished and they also agree*. CMS tables are under construction.

However, I've found a bug for ATLASDY2D8TEV. I don't think it is introduced by this PR but rather a bug in evolve_info (or in the combination of evolve_info, evolve and grids converted from applgrid) so I would wait until this is understood to merge this PR. I've written about the bug here: #72 (comment)

*btw, a bit more than 24 hours to finish all ATLAS FkTable -no jets- using a single core in the eko template.

[andreab1997]

In order to test this I'm redoing all fktables in theory 400.

DIS agree perfectly with what @andreab1997 has in dom for theories 4054 (NLO) and 4244 (NNLO). ATLAS FKTables have already finished and they also agree*. CMS tables are under construction.

However, I've found a bug for ATLASDY2D8TEV. I don't think it is introduced by this PR but rather a bug in evolve_info (or in the combination of evolve_info, evolve and grids converted from applgrid) so I would wait until this is understood to merge this PR. I've written about the bug here: #72 (comment)

*btw, a bit more than 24 hours to finish all ATLAS FkTable -no jets- using a single core in the eko template.

What is the status of this? Can this be merged?

[scarlehoff]

We need a fix (I believe in the pineappl side) for the situation in which evol_info doesn't return the actual grid used during the operation (which axes did) otherwise you won't be able to generate theories with evol_info (in principle also #75 should be broken for the same reason).

@cschwan believes is a numerical precision problem within pineappl

[scarlehoff]

Ok, this is ready. I've updated pyproject.toml since this needs pineappl > 0.6.0 alpha 5

[alecandido]

@scarlehoff can you run poetry lock and upload the updated lock file?

This is what is currently blocking the tests.

[scarlehoff]

Yes... but poetry seems to be having a really hard time resolving the dependencies... (it's about to do 10 minutes...) (I had installed pineappl from the repo so forgot about the lockfile)

[alecandido]

Are you using Poetry 1.4.1? They recently improved a lot the performance (recently = months).

[alecandido]

❯ poetry lock
Updating dependencies
Resolving dependencies... (7.1s)

Writing lock file

[alecandido]

@scarlehoff I'd be in favor of merging :)

[scarlehoff]

❯ poetry lock
Updating dependencies
Resolving dependencies... (7.1s)

Writing lock file

Thanks. I'm at 2490s now... And no, I have poetry 1.2.2. Time to update I guess.