Upload number field data to the cloud

[jwj61]

There are now many more fields. Collections to be copied to the cloud

numberfields.fields numberfields.fields.stats numberfields.fields.rand

[AndrewVSutherland]

I'll copy these tonight -- it may make the number field data unavailable for 5-10 minutes while the indexes are building.

[JohnCremona]

OK, then I'll wait before doing the same for bmfs and ecnf.

[AndrewVSutherland]

This ran into a hiccup last night, I'm going to go ahead and do it now (this might make number fields inaccessible for 5-10 minutes).

[AndrewVSutherland]

The data has now been copied to the cloud. But while checking out the results, I discovered that there is a problem with numberfields.fields.rand, and this problem is also present on beta. If you go to http://beta.lmfdb.org/NumberField/ and click on random number field several times you will eventually get a server error.

@jwj61, is it possible you didn't recreate fields.rand after your latest updates to fields? It has the right number of objects, but the object ids don't all match (this could happen, if, for example, you deleted a bunch of objects from fields and then inserted replacement objects without recreating fields.rand).

It's easy to recopy fields.rand from beta to the cloud, but we should first fix the problem on beta.

[jwj61]

I ran the function to create rand after doing the import/renaming, but I am happy to do it again. In fact, it is running now.

[AndrewVSutherland]

Very strange, maybe something else is going on. Let's test again once the new .rand file is finished.

[AndrewVSutherland]

Okay, this was a complete red-herring, the problem is not in the .rand collection, the problem is that many of the number field pages are throwing a server error because of a type error in a call to pari/GP, and it is easy to hit one of these by clicking on random pages. For example, see

http://127.0.0.1:37777/NumberField/8.4.148761930240000.61 http://127.0.0.1:37777/NumberField/10.2.494887682729.1 http://127.0.0.1:37777/NumberField/8.0.1311242368057344.5 http://127.0.0.1:37777/NumberField/8.0.732894916096.3 http://127.0.0.1:37777/NumberField/10.0.1306069401600000000.11

Based on the random sampling I did, I would guess that about 1/4 of the number fields in the database are affected.

[jwj61]

I have only sporadic internet for a while, but I will look into it.

[jwj61]

Did we change our version of sage recently?

[jwj61]

Never mind on the version of sage, it seems to be a data problem

[AndrewVSutherland]

FYI, I reverted the data on the cloud to the previous version and noticed that there are still some problematic pages, e.g. http://www.lmfdb.org/NumberField/8.0.2156194561585974393979273216.4.

So the problem is not only in the new data.

[AndrewVSutherland]

Also http://www.lmfdb.org/NumberField/8.2.3670390795382784.12

[jwj61]

I just checked a recent addition a little while ago on beta and it was fine, so it may be independent of the recent additions.

[edgarcosta]

JJ, we did not switch the version of sage in the cloud recently. However, Warwick already upgraded to 8.0.

I will build sage 8.0 overnight.

On 14 October 2017 at 20:02, John Jones notifications@github.com wrote:

I just checked a recent addition a little while ago on beta and it was fine, so it may be independent of the recent additions.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/LMFDB/lmfdb/issues/2311#issuecomment-336676034, or mute the thread https://github.com/notifications/unsubscribe-auth/AATtBo5QftLMfwRPU2jFRn4lmGlzaSiaks5ssUuwgaJpZM4P4g7q .

[JohnCremona]

There's one deprecation warning from Sage 8.0 which you see when running the test script: thispolygal = list_to_factored_poly_otherorder(lf[1], galois=True) /home/jec/lmfdb/lmfdb/lfunctions/Lfunctionutilities.py:493: DeprecationWarning: the _pari_ method is deprecated, use __pari__ instead Really there should be no need for us to use this low-level interface to get at this information: Sage should provide it. The "culprit" is in the function list_to_factored_poly_otherorder() in web_g2c.py, which is used in some L-function code, where it extracts the t_number from a Galois group structure in pari format. For some reason Sage has moved from the underlying structure being called via _sage_() to __sage__(). I have been intending to make a small patch for Sage proper to allow accessing the components of this structure without having to know how to obtain the pari object (and then knowing that the T number os item [2]).

[jwj61]

I ran a script looking for fields with faulty data, and all of the bad ones were in degrees 8 and 10. That is where the bulk of the recent additions were. Computing repairs are underway.

[edgarcosta]

FYI, all the servers are now using Sage 8.0

On 15 October 2017 at 10:35, John Jones notifications@github.com wrote:

I ran a script looking for fields with faulty data, and all of the bad ones were in degrees 8 and 10. That is where the bulk of the recent additions were. Computing repairs are underway.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/LMFDB/lmfdb/issues/2311#issuecomment-336715656, or mute the thread https://github.com/notifications/unsubscribe-auth/AATtBqLTrYLNaQzOjXnX8eW2zY-4B3abks5sshgrgaJpZM4P4g7q .

[jwj61]

Recomputing integral bases for octics finished, so those fields won't cause server errors on beta. But, looking at one, you can see that the units are clearly wrong. Both units and integral bases are polynomials in 'a'. It looks like we ended up with just the constant terms of those polynomials, as if a was set to 0 in the pari session where the computation was done. In any case, bases for decics are still going on, and then I will recompute the units.

[jwj61]

Can the numberfield databases (fields, fields.rand, fields.stats) be uploaded to the cloud.

There were problems in two places for many recently added fields. Integral bases had a problem, now corrected. Now the pages will render. The second problem was in rendering of fundamental units -- they would be shown incorrectly. They are temporarily "fixed" by simply saying they are not computed. Computations to rebuild that data is underway. But, the current version would be an improvement over what is on the main site (show field without class group or fundamental units as opposed to giving a server error).

I traced the error back to computing local algebras. This introduced a local/global variable error in computing data to prepare fields for the database. In each batch, the first field was done right, and the rest of that batch had the error.

[AndrewVSutherland]

Copying now, number fields may be slow/unavailable on www.lmfdb.org for the next 10-15 minutes.

[AndrewVSutherland]

Copying is done, pages seem to be OK now (in the sense that I can't seem to hit any server errors by clicking on the random button).