search

NNPDF / pineappl

PineAPPL is not an extension of APPLgrid
https://nnpdf.github.io/pineappl/
GNU General Public License v3.0
12 stars 3 forks source link

Support EKO's new file format #227

Closed cschwan closed 1 year ago

cschwan commented 1 year ago

@AleCandido @felixhekhorn could one of you have a look at commit a735ccf8691c2a244f21724db9fe05454714d265 and tell me if I'm parsing metadata.yaml correctly and if there are any obvious mistakes? When I use the code it doesn't work for the specific example I'm considering.

In particular, I'm unsure whether I'm handling the PIDs correctly. There are _inputpids, _targetpids, pids and I don't know what it means if they're set to null and how to interpret _inputpids.

alecandido commented 1 year ago

In particular, I'm unsure whether I'm handling the PIDs correctly. There are _inputpids, _targetpids, pids and I don't know what it means if they're set to null and how to interpret _inputpids.

If they are null, *pids are equal to pids, and *grid are equal to xgrid.

alecandido commented 1 year ago

These are all internal details of the EKO format, and we didn't consider that PineAPPL was actually parsing EKOs independently.

Because of this, I would move soon the Rust parser into EKO, such that we can keep updating the two consistently (even though we'd like to not update the format too frequently).

cschwan commented 1 year ago

These are all internal details of the EKO format, and we didn't consider that PineAPPL was actually parsing EKOs independently.

Because of this, I would move soon the Rust parser into EKO, such that we can keep updating the two consistently (even though we'd like to not update the format too frequently).

I agree, this is better. For the time being I'm mainly interested in this to debug #226, of course.

alecandido commented 1 year ago

I agree, this is better. For the time being I'm mainly interested in this to debug #226, of course.

I know, and I agree. Debug is more urgent than improvements.

When I said soon™ I didn't mean now ;D

cschwan commented 1 year ago

I think the problem is that the EKO I have uses the evolution basis, and inputpids specifies the evolution basis as a linear combination of the flavor basis. Is that right @AleCandido?

alecandido commented 1 year ago

I think the problem is that the EKO I have uses the evolution basis, and inputpids specifies the evolution basis as a linear combination of the flavor basis. Is that right @AleCandido?

Yes, we used for some time a "fully generic approach", to support a whatever flavor basis. To do this we had to use the rotation matrices.

However, this is sometimes a problem, because we're mostly used to work with PIDs lists, so, when propagated, it gives a lot of troubles. If I remember correctly, we decided with @felixhekhorn and @andreab1997 to stop doing this, and simplify to the only basis we're using externally (i.e. the same of APFEL: canonical, evolution, and unified evolution).

But I'm not sure to which level this decision has been propagated (throughout EKO, to Pineko, and so on).

cschwan commented 1 year ago

What I'm seeing listed in inputpids: in my metadata.yaml is a list of factors that exactly specify the evolution basis. Changing pids0 and lumi_id_types accordingly in the contruction of OperatorInfo in the Metadata::V1 matching arm the code above then works, so that means I can debug #226 now.

cschwan commented 1 year ago

If I remember correctly, we decided with @felixhekhorn and @andreab1997 to stop doing this, and simplify to the only basis we're using externally (i.e. the same of APFEL: canonical, evolution, and unified evolution).

Would that mean that inputpids: would list the PIDs of the evolution basis, similar to pids?

alecandido commented 1 year ago

Would that mean that inputpids: would list the PIDs of the evolution basis, similar to pids?

Exactly :)

cschwan commented 1 year ago

OK, great. One (next-to-?) final question: are all of inputgrid, inputpids, targetgrid and targetpids allowed to be null and if so, these values are taken from xgrid and pids, respectively?

andreab1997 commented 1 year ago

OK, great. One (next-to-?) final question: are all of inputgrid, inputpids, targetgrid and targetpids allowed to be null and if so, these values are taken from xgrid and pids, respectively?

Basically when computing the eko all these parameters are not even used even if they are in the operator card. So the eko is always computed with an interpolation grid given by xgrid and with pids given by pids. Then you can rotate the eko in these spaces and, if you do, targetgrid, inputgrid and so on will be updated in the correct way.

cschwan commented 1 year ago

But what if all of these values are the same, so if there's no rotation, for instance if you generate an EKO for flavor-to-flavor basis, where at each scale the x-grid is the same? I'm asking whether I should allow null in the yaml parser in pineappl evolve.