Flavbasis

[tgiani]

Here I ve cherry-picked the commits regarding the implementation of the flavour basis in n3fit.
Should be ready for merging.

[scarlehoff]

The changes are basically what we want.
I only have the two comments I added: a test would be nice and a more robust way of saying "this is the evolution basis".

[scarlehoff]

Return

[scarlehoff]

We also need a test for this layer in n3fit/tests

Something like computing the rotation in numpy and ensuring the layer produces the same thing.

[tgiani]

ok will do

[tgiani]

I ve added a check for this. Hopefully now it s fine. As I was saying I think a transposition was missing, I ve added it at the level o pdfbases.py, and I ve expanded a bit the docstring to avoid confusion with the indices

[scarlehoff]

Not sure about this, maybe the flav_info should be the one saying whether we are in the evolution basis or not. Otherwise if the user writes "udar" by mistake it would be understood as evolution basis and will produce wrong results.

That said, that the information in the flavour info dictionary is valid should be checked by validphys before going inside n3fit.

[tgiani]

I guess we can either implement some kind of check in vp2, maybe in a separate, or to add an explicit flag somwhere

[scarlehoff]

A check on the input would be needed either way. In the sense that if the user says they are using "evol" the entries in the dictionary should really correspond to that.

[tgiani]

I ve tried to add a check on the input when defining performfit. It looks as if it does the job, but I have no idea if this is the way of doing it

[tgiani]

Ehm..we may have a bug. Assuming that in the runcard the flavour are given with this ordering

(u, ubar, d, dbar, s, sbar, c, g)

then the matrix which brings these vector to

(sigma, g, v, v3, v8, t3, t8, cp)

is

[[ 1.  1.  1.  1.  1.  1.  2.  0.]
 [ 0.  0.  0.  0.  0.  0.  0.  1.]
 [ 1. -1.  1. -1.  1. -1.  0.  0.]
 [ 1. -1. -1.  1.  0.  0.  0.  0.]
 [ 1. -1.  1. -1. -2.  2.  0.  0.]
 [ 1.  1. -1. -1.  0.  0.  0.  0.]
 [ 1.  1.  1.  1. -2. -2.  0.  0.]
 [ 0.  0.  0.  0.  0.  0.  2.  0.]]

In FlavourToEvolution we have

self.tensor_product(x_raw, self.rotation_matrix, 1)

with x_raw.shape = (dim0,dim1, 8) and rotation_matrix given above with shape (8,8).
If each entry of the axis 2 in x_raw represents a flavour, then we should transpose the rotation matrix before doing the tensor product I think.

[tgiani]

I think this bug was introduced when replacing

x_flav = self.transpose(x_raw)
pdf_evol = self.tensor_product(self.rotation_matrix, x_flav, 1)
return self.reshape(pdf_evol, x_raw.shape)

with

return self.tensor_product(x_raw, self.rotation_matrix, 1)

in the call function of FlavourToEvolution. The two things are not equivalent if we don t transpose the matrix I think. Sorry, will check again, fix it and run again some test

[scarlehoff]

I think this bug was introduced when replacing

x_flav = self.transpose(x_raw)
pdf_evol = self.tensor_product(self.rotation_matrix, x_flav, 1)
return self.reshape(pdf_evol, x_raw.shape)

with

return self.tensor_product(x_raw, self.rotation_matrix, 1)

in the call function of FlavourToEvolution. The two things are not equivalent if we don t transpose the matrix I think. Sorry, will check again, fix it and run again some test

The tensorproduct with axes=1 is basically a dot product between argument a and b so the first argument in the matrix should be the "flavour index" and the second the "evolution index".

In any case, this is exactly why a test where the rotation is done in numpy and then compared to the answer of this layer is important :P

[tgiani]

yes. The first index (the line) of the matrix above refers to the evolution index, while the second index refers to the flavour index, so we need to transpose it.

In any case, this is exactly why a test where the rotation is done in numpy and then compared to the answer of this layer is important :P

yep

[scarlehoff]

I guess @Zaharid should chime in on right way of checking for input. I think I'd do something similar.

The only thing I'd add is a check to ensure that no flavour is repeated.

As a desire, I'd take also as input the name of the basis and check that the allowed labels are the ones that correspond to the chosen basis.

[Zaharid]

This could indeed use the stuff we already have, and implement a check similar to

nnpdf/validphys2/src/validphys/pdfbases.py

Line 52 in a00dc22

def check_basis(basis, flavours):

[tgiani]

I ve run a test with the code from this branch after fixing the transposition of the rotation matrix.
The name of the fit is 010520-flavbas-tg : no preprocessing, no sum rules. Here s the corresponding report, where I m comparing it with the bugged one 220420-flavbas-tg
https://vp.nnpdf.science/MQUAcCW-SmiC9l5Ib_oldQ==/

[tgiani]

@scarlehoff @Zaharid are you happy with this PR?

[scarlehoff]

Let me go through it (and push a minor change to the Rotations.py), specifically now that there is more than one rotation Rotation should have another name.

[scarlehoff]

I'm happy with the PR, the only comment is the one about the check. We can use the existing functionality (that way we ensure the basis used in n3fit will always be the ones defined in the vp pdbases)

[tgiani]

I m a bit confused about the reason the checks are failing..they pass on mac but not on linux, but if I try to run on my laptop the test which is failing I don t have any problem

[scarlehoff]

@Zaharid, any reasons not to use np.testing.assert_allclose? Their error messages are very helpful in situations like this one.

In any case, the situation seems to stem from here

nnpdf/validphys2/src/validphys/calcutils.py

Line 179 in 4bd456d

if 1 / e_val[0] <= sqr_threshold: # eigh gives eigenvals in ascending order

because if one of the eigenvalues is 0 it might happen to become -1e-17 so 1/almost_0- is almost -inf and the condition is True.