nnpdf icon indicating copy to clipboard operation
nnpdf copied to clipboard

Avoid recomputing theory covmat in `vp-setupfit` for iterated fits.

Open giacomomagni opened this issue 1 year ago • 7 comments

When running vp-setupfit of an iterated fit, and if there are not changes in runcard setting affecting the theory (this is the default situation, as no one changes theory settings during an iteration ), the theory covmat should not be recomputed from scratch, but imported form the previous fit.
This can save some time (from 10 minutes to 1 hour).

giacomomagni avatar Jan 17 '24 16:01 giacomomagni

So it should take the covmat from the t0pdfset?

Maybe instead of doing this automatically we should add a flag under theorycovmatconfig?

RoyStegeman avatar Jan 17 '24 16:01 RoyStegeman

So it should take the covmat from the t0pdfset?

you can just copy the covmat of the previous fit (as long as you don't change your theory settings in vp-nextfitruncard)

giacomomagni avatar Jan 17 '24 17:01 giacomomagni

But how do I know what the previous fit is?

RoyStegeman avatar Jan 17 '24 17:01 RoyStegeman

ehh this can indeed be tricky as there is not a unique naming convention. I have 2 solutions:

  • vp-nextfitruncard can run directly vp-setupfit, and this way you know where you are starting from. Ideally there are no addional steps that prevent to run just after vp-setupfit (we can also have a new vp action if that is easier).
  • you can pass a flag to vp-setupfit with the original fit name. This has the benefit that there might be other cases where you don't want to recompute the th covamat.

giacomomagni avatar Jan 17 '24 19:01 giacomomagni

The first option I don't like since I rarely immediately want to run vp-setupfit after running vp-nextfitruncard. Specifically, I'd rather run vp-setupfit on a cluster node than in the login node.

The second option indeed comes close to my suggestion of adding a flag under theorycovmatconfig, but instead of making it boolean flag we should make it a string with the name of the previous fit. Right now I can't think of any objections to this, so maybe that's what we can do.

RoyStegeman avatar Jan 17 '24 20:01 RoyStegeman

Both'd fine for me.

The first option I don't like since I rarely immediately want to run vp-setupfit after running vp-nextfitruncard. Specifically, I'd rather run vp-setupfit on a cluster node than in the login node.

If you aren't computing the theory covmat vp-setupfit takes seconds no?!

giacomomagni avatar Jan 17 '24 22:01 giacomomagni

I think the point is that the next runcard you might be creating in your laptot, if you do it there you need to upload the entire folder.

I'd also favour the explicit, manual, from: <some previous fit> key. That way you are sure you are not reusing the same covmat by mistake.

Just a few notes for reference for the one implementing this, it should be checked that

  1. The theory setrings are the same
  2. The new runcard's datasets and cuts are a subset of the old ones

and fail otherwise

scarlehoff avatar Jan 18 '24 07:01 scarlehoff