Wrong L-fucntion association with ECNF

[edgarcosta]

The L-functions associated with the isogeny classes:

2.0.11.1-9900.5-a
2.0.11.1-9900.5-d
2.0.11.1-9900.5-e
2.0.11.1-9900.5-f 
2.0.11.1-9900.5-k

are not correctly assigned. In particular, for these 5, the Dirichlet coefficients do not match for a bunch of primes.

More confusing, is that if I look at the isogeny class from which I computed this L-function they all point to themselves except
for 2.0.11.1-9900.5-f the origin was 2.0.11.1-9900.5-h.

Was there a relabeling of these isogeny classes?

For example,
https://beta.lmfdb.org/L/4/1197900/1.1/c1e2/0/28
points to
https://beta.lmfdb.org/EllipticCurve/2.0.11.1/9900.5/d/
but also indicates that it should be the L-function of the base change of
https://beta.lmfdb.org/EllipticCurve/Q/330/b/
(by looking at the zeros this seems right)
One of the curves on that isogeny class has j-invariant $1263214441/211200$
https://beta.lmfdb.org/EllipticCurve/?field=2.0.11.1&jinv=1263214441%2F211200
which leads me to the isogeny class
https://beta.lmfdb.org/EllipticCurve/2.0.11.1/9900.5/e/

Here are the permutations I have figured out so far by hand:

label	Listed isogeny classes	Correct isogeny classes
4-1197900-1.1-c1e2-0-18	2.0.11.1-9900.5-b 2.0.11.1-9900.5-c	2.0.11.1-9900.5-c
4-1197900-1.1-c1e2-0-24	2.0.11.1-9900.5-a	2.0.11.1-9900.5-b
4-1197900-1.1-c1e2-0-28	2.0.11.1-9900.5-d	2.0.11.1-9900.5-e

but I should certainly automate this.

No L-function found via first zero:

• 2.0.11.1-9900.5-a

[JohnCremona]

I haven't added to the data over that field since 2017, except to add extra data columns to existing rows/curves.

Looking at my git logs I see this which looks relevant:

commit 95b28749620c463524f5de9f2049fc0e2f7a801c
Author: John Cremona [email protected]
Date: Thu Jun 22 12:44:28 2017 +0100

2.0.11.1: added 2 missing of norm 9900 and all 20k-30k

This tells me that something nonstandard happened precisely for this field and level norm 9900. Using git I found out which curves were the two I added (though this should not affect the labeling): they were in the isogeny classes with old labels 2.0.11.1-9900.150.30-m (6 curves) and 2.0.11.1 9900.150.30 l (4 curves). The new label for that ideal is 9900.5 so the curves added later are in classes 2.0.11.1-9900.5-m and 2.0.11.1-9900.5-l. This does not seem to match what you are seeing though it is the same level where you found a discrepancy, just not the same isogeny classes.

In case it helps, my newform data for this level contains these 13 newforms a-m. The last two lists are of A-L eigenvalues and of the coefficients a_P for the first 15 primes P (both good, where a_P = Hecke eigenvalue, and bad, where a_P = 0,+1 or -1). For this level the first 6 primes are bad, the rest are good.

2.0.11.1 9900.5 a (-30+60a) 2 1 0 1 14 [1,1,-1,1,1,1] x [-1,-1,1,-1,-1,-1,-4,-4,0,0,-10,-10,-4,-4,2]
2.0.11.1 9900.5 b (-30+60a) 2 1 0 -1 0 [1,1,-1,1,1,-1] x [-1,-1,1,-1,-1,1,4,4,8,8,-2,-2,-4,-4,-14]
2.0.11.1 9900.5 c (-30+60a) 2 0 0 -1 0 [1,1,-1,1,-1,1] x [-1,-1,1,-1,1,-1,-4,-8,-4,4,2,2,12,0,2]
2.0.11.1 9900.5 d (-30+60a) 2 0 0 -1 0 [1,1,-1,-1,1,1] x [-1,-1,1,1,-1,-1,-8,-4,4,-4,2,2,0,12,2]
2.0.11.1 9900.5 e (-30+60a) 2 1 0 -1 0 [1,1,-1,-1,-1,-1] x [-1,-1,1,1,1,1,0,0,-8,-8,-10,-10,0,0,2]
2.0.11.1 9900.5 f (-30+60a) 2 1 0 -1 0 [1,1,-1,-1,-1,-1] x [-1,-1,1,1,1,1,0,0,0,0,6,6,-8,-8,-14]
2.0.11.1 9900.5 g (-30+60a) 2 0 0 -1 0 [1,-1,1,1,1,-1] x [-1,1,-1,-1,-1,1,-4,8,4,4,-10,-6,0,8,2]
2.0.11.1 9900.5 h (-30+60a) 2 0 0 -1 0 [1,-1,-1,-1,-1,1] x [-1,1,1,1,1,-1,-8,0,0,-8,-10,6,8,-8,-6]
2.0.11.1 9900.5 i (-30+60a) 2 0 0 -1 0 [-1,1,1,1,1,-1] x [1,-1,-1,-1,-1,1,8,-4,4,4,-6,-10,8,0,2]
2.0.11.1 9900.5 j (-30+60a) 2 0 0 -1 0 [-1,1,-1,-1,-1,1] x [1,-1,1,1,1,-1,0,-8,-8,0,6,-10,-8,8,-6]
2.0.11.1 9900.5 k (-30+60a) 2 0 0 -1 0 [-1,-1,1,1,1,1] x [1,1,-1,-1,-1,-1,-4,4,8,0,-10,-2,-12,-4,6]
2.0.11.1 9900.5 l (-30+60a) 2 0 0 -1 0 [-1,-1,1,1,1,1] x [1,1,-1,-1,-1,-1,4,-4,0,8,-2,-10,-4,-12,6]
2.0.11.1 9900.5 m (-30+60a) 2 1 0 1 4 [-1,-1,-1,-1,-1,1] x [1,1,1,1,1,-1,0,0,0,0,-2,-2,8,8,-14]

I am not sure what to do next. I could recompute all the data for just this level without much difficulty (or time) but that is only really helpful if what happened here did not happen elsewhere.

[JohnCremona]

I have a script I can run on legendre which will check for a given field whether the curves and BMFs match: bijection with traces of Frobenius matching Hecke eigenvalues for each label. That is worth doing (so I will, and will report back here). If that shows up nothing then is it possible that ordering of the newforms / isogeny classes at this (and possible some other) levels are not what they should be, namely by lexicographically ordering the list of coefficients a_P, with the primes P in the standard order and including the bad primes? That is something else I can check separately, for this level.

[JohnCremona]

NB I edited the previous*2 comment to correctly say that the list of a_P includes all good and bad primes. These are the prime-index coefficients of the L-function when written as a sum over integral ideals of the field. You can check from the lists above that they are in correct lex order.

[JohnCremona]

And I have also checked that the 13 isogeny classes at level 2.0.11.1-9900.5 are in the correct order, which matches the order of the associated newforms.

So all that is wrong is (from what you reported) that these curves have the wrong L-function link. Looking at the code (in lmfdb/ecnf/WebEllipticCurve.py, lines 862ff) that comes from lines 757ff :
lfun_url = url_for("l_functions.l_function_ecnf_page", field_label=self.field_label, conductor_label=self.conductor_label, isogeny_class_label=self.iso_label)
-- and that is calling a function I did not write. So what appears to be the immediate cause of the problem is that when you put L/ into the page's URL, you get the wrong L-function, and that could be because when these L-functions were computed something was done incorrectly -- or that some labels have changed since that was done.

Aha! looking again at the git log for the file which contains these curves, as well s the commit which I reported on above, I also see this one:

commit 5847045028912686c22527ff8510e68cb5614bb9
Author: John Cremona [email protected]
Date: Fri Apr 17 16:47:40 2020 +0100

corrected data for 2.0.11.1-9900.5

and while I do not have an note for what the corrections were, it is quite possible that this was indeed a sorting issue resulting in the labels for this level only being changed, possibly after the L-functions were computed. I will look carefully at the diffs to see if that is the case and if so, what the permutation is.

[JohnCremona]

After looking carefull at the curves at level 9900.5 before and after the commit on 2020-04-17, my conclusion is this. On 2017-06-22 (the first commit I referenced above) two more newforms/classes were added, taking the number from 11 to 13 BUT they were added at the end of the list and labelled l and m, instead of inserting them where they should have gone, which could (and would) mean changing all the other labels. As luck would have it, one of the new classes ended up as 'a'.

I think it will be best to recompute all 13 of these L-functions and change the L-functions database accordingly, but alternatively, the permutation (old-label --> new-label) is

a --> b --> c --> d --> e -->g --> i -->k --> m
f --> h --> j --> l

and the 2 which were added late are a and f (l --> a, m --> f).

I don't know when the L-functions for these were computed.

[edgarcosta]

I also verified that for all the 125419 L-functions originating from ECNFS only the 2.0.11.1-9900.5-* show issues.

While I agree that one should perhaps recompute them, for the time being, I will try to fix the URLS in the database, in particular, we will be missing the L-function for the a and the f.

[JohnCremona]

That is good, I am relieved that there were no other discrepancies.

The ECNF table does include the hash which should agree with the L-functions hash. Perhaps we should check that these agree in cases where we create the L-function's URL directly from the curve's URL.

[edgarcosta]

Under the mapping

2.0.11.1-9900.5-a --> 2.0.11.1-9900.5-b
2.0.11.1-9900.5-b --> 2.0.11.1-9900.5-c
2.0.11.1-9900.5-c --> 2.0.11.1-9900.5-d
2.0.11.1-9900.5-d --> 2.0.11.1-9900.5-e
2.0.11.1-9900.5-e --> 2.0.11.1-9900.5-g
2.0.11.1-9900.5-g --> 2.0.11.1-9900.5-i
2.0.11.1-9900.5-i --> 2.0.11.1-9900.5-k
2.0.11.1-9900.5-k --> 2.0.11.1-9900.5-m
2.0.11.1-9900.5-f --> 2.0.11.1-9900.5-h
2.0.11.1-9900.5-h --> 2.0.11.1-9900.5-j
2.0.11.1-9900.5-j --> 2.0.11.1-9900.5-l

all the trace hashes match

[edgarcosta]

I will take care of fixing the L-function matching. It involves several simultaneous changes for things not to break, I will wait for a later time in the month to do this.