Recover plot operators about eko

[alecandido]

Hi guys, sorry for stepping in, I have a naive question, why in the op plots the last grid points (bottom right corner) are not a triangular matrix... I see they contain small values, but they shouldn't be there at all no?

It's a relevant question, and you have to add that last row is also empty, but we have answers for this (and at least the second one you should know, since you implemented yourself):

• it's not triangular because of interpolation, you need at least that many points (interpolation_degree + 1)
• last row is empty, because the PDF it's constrained to be 0 at z=1 f(z=1) = 0, thus it is completely independent from the input (nevertheless it's nice to have square operators, and it's not a huge waste to add one line, while it would be harder to maintain to have a rectangular operator and having to add one point manually to the output PDF)

[alecandido]

Please, can you add some details and how to reproduce?

[andreab1997]

@alecandido Since we found the problem and changed the colormap, I think we can close this issue, right?

[alecandido]

I think so as well :)

Maybe last thing is: check how they look like in evolution space (in principle should be much easier, since you should only have relevant elements for S.S, S.g, g.S, g.g, T3.T3, V3.V3, ..., and not the full square).

[alecandido]

Maybe last thing is: check how they look like in evolution space (in principle should be much easier, since you should only have relevant elements for S.S, S.g, g.S, g.g, T3.T3, V3.V3, ..., and not the full square).

Most likely it won't happen, because the operator is computed before in flavor space. A possible solution is to introduce some kind of tolerance when checking the absolute maximum, and ignore operators that have all elements below.

[andreab1997]

Maybe last thing is: check how they look like in evolution space (in principle should be much easier, since you should only have relevant elements for S.S, S.g, g.S, g.g, T3.T3, V3.V3, ..., and not the full square).

Most likely it won't happen, because the operator is computed before in flavor space. A possible solution is to introduce some kind of tolerance when checking the absolute maximum, and ignore operators that have all elements below.

Problem is that I noticed now that plots.py only plots on pid labels. So first I need to change this

[alecandido]

Ok, good to have found out.

[andreab1997]

Ok, good to have found out.

Now the plots in evolution basis should be available. However, I found another bug. When you run sandbox in flavor_basis it will not work. Speaking to @felixhekhorn, he said that it is related to how the caching is done and that it is a known bug. So, should I close this issue @alecandido?

[alecandido]

Thank you very much for your progresses @andreab1997, about the two points:

• before closing the issue, I'd like to see the plots in evolution basis, if they are fine I'd be happy to actually close (for the sake of speed, and by the way reporting, can you post a PDF in a comment in this issue, please?)
• concerning the flavor_basis I don't perfectly remember the issue, but I've an idea, and I agree that is a completely decoupled problem, so, if ever, we'll open a separate issue

[andreab1997]

Yes, I post here the PDF with the plot in ev.basis
off080e_tedfbed.pdf

[alecandido]

You see that some are not worth to plot, like V3.V:

because it's fully non-singlet and non-diagonal, but also V.g:

that looks much smoother, it's still not worth, if you look at the scale.

So I would filter them out putting a threshold, maybe at 10^-8.
Moreover, try to translate the names according to the map in basis_rotations, since these flavors code we made up ourselves and are little understandable to anyone else (at the moment they are not even present in the docs...).

[andreab1997]

You see that some are not worth to plot, like V3.V:

because it's fully non-singlet and non-diagonal, but also V.g:

that looks much smoother, it's still not worth, if you look at the scale.

So I would filter them out putting a threshold, maybe at 10^-8. Moreover, try to translate the names according to the map in basis_rotations, since these flavors code we made up ourselves and are little understandable to anyone else (at the moment they are not even present in the docs...).

Yes, sorry you had already mentioned the threshold stuff. Anyway, now it should work. I'm posting the new pdf.
off080e_tedfbed.pdf

[alecandido]

Yes, sorry you had already mentioned the threshold stuff. Anyway, now it should work. I'm posting the new pdf.

Don't mind, that's exactly how the old plots looked like, and it's perfectly recovered.

Thank you for your effort, I think we can close!

[giacomomagni]

Hi guys, sorry for stepping in, I have a naive question, why in the op plots the last grid points (bottom right corner) are not a triangular matrix... I see they contain small values, but they shouldn't be there at all no?
If not too much, it will be nice to rescale the axes in the range [x_min, 1] instead of the grid binning

[felixhekhorn]

Hi guys, sorry for stepping in

don't mind, as a core developer you can step in any time ;-)

, I have a naive question, why in the op plots the last grid points (bottom right corner) are not a triangular matrix... I see they contain small values, but they shouldn't be there at all no?

now the behaviour at the border of the grid, is exactly as we defined the interpolation - i.e. in esp. at the top border of the grid the top, say 4, polynomials are active, since those are the 4 nearest (given polynomial degree 3)

[alecandido]

If not too much, it will be nice to rescale the axes in the range [x_min, 1] instead of the grid binning

I guess you are speaking of relabeling the axes (that's feasible) with z values (I keep calling z, you know why), but bins are bins (those are matrix entries), so I would keep the binning explicit (even in the relabeled variable)

[giacomomagni]

This has been solved right?

[alecandido]

I guess so. @andreab1997?

[andreab1997]

I guess so. @andreab1997?

Yes, it is solved.