Evolve n3fit with eko 0.12 #1694
Conversation
|
Just to clarify, this version is working (@giacomomagni is using it) but there is still some work to do (example: fixing tests). So let me convert this to Draft and I am going to take care of this. |
|
For the moment we have a known dependencies problem with conda conda-forge/eko-feedstock#11 |
|
The dependencies problem is now fixed! |
|
Are these passing locally for you? Just because if they're not, it's probably easier to run only the regression tests locally as opposed to pushing to test. |
Actually the test that is failing should no be linked to evolven3fit so I don't understand why it is failing here |
|
If I have to guess it would be because the change in eko came with a change in the numpy version being used so that messed up with the seeding at some stage, and the fit is very sensible to changes. So you would need to rerun the regression test locally and update the results. (assuming this branched out of master) |
So that test is only for linux. If I run locally on my mac it is succeding. Can someone with linux try? |
I don't think it is being run at all. Also, you would need to run it with a clean conda installation to be in the CI configuration. |
I know, I commented the line that is making the test running only on linux |
And is it running in an environment which is exactly the one in the CI? (which is in practice a perfectly clean conda installation) |
|
I would be surprised if the numpy version influences the seeding. The "old" numpy random interface that we use is guaranteed to never change afaict. |
|
I don't think it is guaranteed but I agree that is surprising. Maybe something else changed version (I haven't compared side by side all packages, I only noticed the bump in the numpy version). |
scarlehoff
left a comment
There was a problem hiding this comment.
lgtm
@niclaurenti I think you can safely rebase on top of this branch.
Co-authored-by: Juan M. Cruz-Martinez <[email protected]>
Co-authored-by: Juan M. Cruz-Martinez <[email protected]>
|
Thanks guys, please give me a sec to have a look |
RoyStegeman
left a comment
There was a problem hiding this comment.
Some suggestions but looks good otherwise
| if key in op_card_dict and isinstance(op_card[key], dict): | ||
| op_card[key].update(op_card_dict[key]) | ||
| elif key in op_card_dict: | ||
| _logger.warning("Entry %s is not a dictionary and will be ignored", key) |
There was a problem hiding this comment.
I'm wondering if at this point it should just raise an error. If a code runs and returns something that looks halfway alright I don't check the logs.
Whenever there is a key in a dictionary there may have been a reason for it to be there and if it was put in the wrong place/mistyped or something like that it's good if it raises an error. Probably outweights the few times it would raise an error when unnecessary.
There was a problem hiding this comment.
In general I agree. The point is that in this case the only thing that an user can pass and that would be ignored are the Q2 and x grids which, in the particular case of the postfit evolution, I don't thing will be source of confusion.
There was a problem hiding this comment.
What is the use case of op_card_dict? Is this something that the user is expected to use or is it more an "advance use case" / for debugging / etc?
There was a problem hiding this comment.
I would say that in general the user is not going to use it. The only real use case is if he wants to change the solution of the evolution or something like that and this is actually possible. The only two things that at the moment cannot be changed are the q-grid and the x-grid but I would say that they are usually not changed when one does the postfit evolution.
Co-authored-by: Alessandro Candido <[email protected]>
| info["XMax"] = float(x_grid[-1]) | ||
| dump_info_file(usr_path, info) | ||
| for replica in initial_PDFs_dict.keys(): | ||
| evolved_block = evolve_exportgrid(initial_PDFs_dict[replica], eko_op, x_grid) |
There was a problem hiding this comment.
Performance tip: if you put the iteration over
The best way would be to keep the EKO iteration outer, at the price of building the blocks in memory and dump all of them at the end.
However, this only regards performances, from any other point of view it should be perfectly equivalent.
| xgrid=targetgrid, | ||
| Q2grid=list(eko["Q2grid"]), | ||
| pids=br.flavor_basis_pids, | ||
| Q2grid=list(eko.mu2grid), |
There was a problem hiding this comment.
Later on I would consider:
| Q2grid=list(eko.mu2grid), | |
| mu2grid=list(eko.mu2grid), |
For consistency with:
- new EKO notation
- physical meaning
- Python naming (PEP 8)
But of course this would follow from the matching change in the function in genpdf. But actually that is already done in a PR NNPDF/eko#220, so consider this more as a warning for the future...
There was a problem hiding this comment.
Ok I can keep this open as a warning
Co-authored-by: Juan M. Cruz-Martinez <[email protected]>
This PR is to update
evolven3fit_newwitheko=0.12.0.This is needed for developing since
eko=0.10.3is not compatible anymore with N3LO and QED #1643.cc @scarlehoff