Make code public

[cschwan]

Someone suggested to make patches public, which I also think is a good idea. I suggest we'll start from the publicly released Vrap and provide the following patches:

1) One that fixes all the bugs/quirks so that Vrap compiles with modern C++ compilers (basically https://github.com/NNPDF/external/pull/58) 2) The patch to supports the piso collider 3) PineAPPL support.

[cschwan]

If we have this we should offer this to upstream, having this in a public release would be great!

[scarlehoff]

I was about to send an email about this. Basically before making it public we should ask Lance Dixon and/or Frank Petriello https://www.slac.stanford.edu/~lance/Vrap/ if they are ok with us making a derivative of vrap with

Patch that fixes all the bugs/quirks so that Vrap compiles with modern C++ compilers (basically https://github.com/NNPDF/external/pull/58) The patch to supports the piso collider PineAPPL support.

Then I'll move this repository as is to the NNPDF organization and make it public there.

If they are not happy with it then it has to stay in external as a secret NNPDF private code.

The purpose the idea of making it public serves is that the runcard runners can also be used by non-NNPDF people.

[scarlehoff]

Do any of you (@cschwan @enocera) know one of the two guys? If yes, could you send the email? If now I'll try to write a very formal email.

[enocera]

@scarlehoff I've met both of them a couple of times, though I don't think that this qualifies me to say that I know them (or, more importantly, that they know me). But if you prefer me to send the email, I'm available to do so.

[scarlehoff]

yes, that would be great, thanks!

[enocera]

@cschwan @scarlehoff I've just sent the email to Frank. Let's see what he'll say (if he'll say something).

[cschwan]

@enocera Thanks a lot!

[scarlehoff]

Given the email we just received from Frank, let's wait and check whether DYrap and Vrap actually produce the same numbers. Of course we've checked that vrap is compatible with apfel for FTDY but I guess an extra check is never harmful.

[enocera]

@scarlehoff We cannot do this check, because we don't have DYrap (unless we ask it explicitly to Frank). Do you? We certainly use Vrap-0.9, but we have a quite restrictive cut on tau=M^2/s, which, I guess, removes the problem mentioned by Frank.

[scarlehoff]

It's available in Lance Dixon's homepage https://www.slac.stanford.edu/~lance/Vrap/ We can check that the problem is indeed sub-permille (likely) for our use-case and then we can answer with certainty that we are not affected by this bug.

[enocera]

@scarlehoff Are you able to download the code if you click on the link? I'm not...

[scarlehoff]

Yes. It's 18k lines of Fortran which makes me unsure on whether we will be actually able to run it satisfactorily. But I will try.

[cschwan]

@enocera when I try to open it in my browser it doesn't work, but manually downloading it with wget and extracting with tar works!

[enocera]

I see, thanks.

[scarlehoff]

Ok, so the only PDF set in the DYrap code is MRST2004 which is in a format different from LHAPDF and MRST2004 is not in LHAPDF. As a result I cannot run vrap and DYrap and get the same numbers without playing some tricks.

I think that would be more work than it is worth*, I think we should just answer to Frank that for the kinematic ranges we are interested in the effect is negligible and that we checked with a third-party code (Apfel). And of course add the caveat he asked us for.

*surprisingly enough, the code just compiles with -std=legacy in gfortran. That was easier than expected :P

[cschwan]

I agree. @enocera would you like to answer them?

[enocera]

Excellent, yes, I'll reply to them.

[enocera]

Just for the record, threshold effects in fixed-target DY were studied in https://arxiv.org/pdf/1507.01006.pdf some time ago, by interfacing Vrap with TROLL (A code by Marco Bonvini and Luca Rottoli).