Finally fixing Siegel Modular Forms (or at least paramodular)

[wbl]

Siegel modular forms are a hard problem for the LMFDB and have been for years. And the gap between what we know and what we show has gotten bigger. There's several different kinds of information we can have about a form or a space and some spaces have much more of it than others, and several different kinds of form that can populate a space.

I feel there have been some efforts sitting around I don't know about and I've taken a crack at it in the past (with limited success) so maybe there is some work sitting around I don't know about. I'm opening this issue to a) volunteer to take another wack at it and b) make sure I know what we want it to look like before we get started. But now we have more data.

• To start with it's worth dropping everything but k=3 paramodular forms. We can do this while not breaking navigation after a later addition: Siegel can redirect to pages for specific cases, including paramodular. The navigation hierarchy in the bar would go home -> Siegel -> Paramodular even if the left hand navigation bar goes to Paramodular. I'm sad about this but k=2 has only a few examples and the others have nothing.

• Each level has a page with number of forms, nonlifts, and links to particular forms. Each type G form has a type and Hecke eignvalues/Euler factor and link to L-function when it exists. If it doesn't it should be added. Type Y or P should have link to the classical modular forms they come from. This might take some work. Coefficient fields should be linked to, this might be a bit messy. Worst case just list the forms and their Euler factors/L-functions.

• If we have Fourier coefficients they should be presentable. This is only a handful of forms and really recent work! Maybe it's computable in lifts, but all we need is the DB shape to store it, and maybe not that.

• Knowls need to be fixed up and edited

Once that's landed we can have a conversation about how to handle the rest. I might even start with fixing M_2(K(p)) first without a lot of niceties, and then we have a foundation for the rest of

[edgarcosta]

Hi Watson, it has been a while.
Recently, there has been some progress in thinking about Siegel modular forms, you can see it for the time being here: https://pink.lmfdb.xyz/ModularForm/GSp/Q/
which points to https://github.com/assaferan/lmfdb/tree/smf_lmfdb

A good chunk of the progress happened during this week:
https://icerm.brown.edu/program/simons_collaboration/sc-23-smf
I think the people to get in touch with are: @assaferan, @tornaria, and @jvoight.

[tornaria]

@assaferan Did pink somehow reverted to the old version of SMF?

[edgarcosta]

@assaferan Did pink somehow reverted to the old version of SMF?

It is most likely my fault. To what branch should it point to?

[assaferan]

@edgarcosta - it is smf_week. Indeed, does not look like pink points there. There were some changes in master that broke it, but it seems to be running now.

[edgarcosta]

Now pointing to smf_week

[roed314]

Btw, the branches pointed to by each color server are now visible at https://beta.lmfdb.org/static/color-branches.txt.

[wbl]

Pink looks great, don't have any more comments. What would it take to get it into beta or into master? Happy to pitch in

[assaferan]

There are several things, among which I think the most important are:

1. Populate it with data. There are new tables for smf that need to be populated with existing data.
2. Add tests to make sure things work, and as many verifications as we can that the data is correct.
3. Verify that we do not lose features the old pages used to have.
   I have also invited you to a Zulip where these things were discussed, and to a separate GitHub repo (https://github.com/assaferan/smf_lmfdb/) where we work on the code for generating the data.

[assaferan]

I opened issue #6260 for the concrete goal of merging pink into beta by v1.3, but I'm leaving this one also open. Once we merge pink, we can take another look at this issue, and see what more needs to be done.