Bmf0curves

[JohnCremona]

See #3058 for the associated Feature Request.

Some Bianchi newforms (weight 2, rational eigenvalues) do not have associated elliptic curves, though most do, and of those which should do we have curves in almost all cases but not quite all. The new column 'curve_status' in the table bmf_forms allows this information to be displayed in a better way than just looking up on the fly whether or not there is a curve with some ad hoc method to tell whether it does not exist or is simply missing. This column has been correctly filled for the BMFs currently in the database: 228896 forms, of which 228687 have curves, 193 do not have curves, and 16 should do but I have not yet found them; the value of 'curve_status' is 1, -1, 0 respectively:

sage: [(n,db.bmf_forms.count({'curve_status':n})) for n in [-1,0,1]]
[(-1, 193), (0, 16), (1, 228687)]

I added a section on the home page of a BMF headed "Associated elliptic curves" with one of three possible text templates.

Examples:

1. Normal (curve exists):

http://localhost:37777/ModularForm/GL2/ImaginaryQuadratic/2.0.3.1/106176.1/a/

(text says "This Bianchi newform is associated to the isogeny class 2.0.3.1-106176.1-a of elliptic curves.")

2. Elliptic curve should exist but is missing:

http://localhost:37777/ModularForm/GL2/ImaginaryQuadratic/2.0.511.1/100.5/a/

(text says: "This Bianchi newform is conjectured to be associated to an isogeny class of elliptic curves, but no matching elliptic curve is currently known.")

3. No elliptic curve exists:

http://localhost:37777/ModularForm/GL2/ImaginaryQuadratic/2.0.568.1/9.1/a/

(text says: "This Bianchi newform is not associated to any elliptic curves.")

I am open to suggestions for alternative wording, and for a knowl to be attached to the section heading. Note that this is not primarily about modularity of elliptic curves over imaginary quadratic fields, which is now known (thanks to Newton and Caraiani) for half the fields, but about whether the geometric object attached to a BMF is an elliptic curve or something of higher dimension; there are papers which the knowl should refer to.

I wrote the code so that if this is pushed to prod before the tables are then it should work, but I am also here asking for bmf_forms and ec_nfcurves both to be copied to prod. (The latter because I added a couple of doxen relevant curves recently, see #6112 .)

[JohnCremona]

Please hold off copying bmf_forms and ec_nfcurves until I have finished a new data upload (see #6112), then also bmf_dims will need copying. Thanks.

The extra data has now been uploaded so bmf_dims, bmf_forms and ec_nfcurves are all ready to be copied to prod.

[JohnCremona]

Note that the extra BMF data uploaded causes one test in test_bmf to fail but that is fixed in PR #6356 . These two PRs can be merged in either order.

[roed314]

So this is ready to go, and doesn't need to wait on any more data being copied?

[JohnCremona]

Yes: the code in this PR uses the new column if it exists but otherwise defaults to the old behaviour. So it will certainly run fine on beta, and should also run fine on prod both before and after the data is copied over.

[JohnCremona]

@roed314 Hold on -- I am testing that the code works OK when the curve_status column is absent by changing the one instance of self.curve_status in the code to self.curve_status_bogus, and it is not quite right. To be fixed shortly...

[JohnCremona]

OK now. This code has now been tested to work whether or not the curve_status column is present in the table bmf_forms (which it is not yet on prod, though it is on beta).