This section contains a sketch of how databases of examples can be built. This is an aside from the rest of the chapter, and is only of interest if one either wants to understand the construction of the K3 database for its own sake, or wishes to create other similar lists that take too long to be regenerated on demand. Note, however, that the database facility described here is not suitable for very large databases: roughly speaking, it is intended for those containing a few tens of thousands of elements, not millions, and certainly not in the Kreuzer--Skarke [KS00] range.
This section describes briefly the method of construction used for the K3 database. The K3 database is fully installed in Magma---see Section The K3 Database for instructions---and there is no need to use the functions described here to rebuild it unless you intend to modify the code to incorporate new information in the database.
The construction is in two steps. First we create all the K3 surfaces we require and write them as abbreviated records to a series of files. Then we load these files one at a time, writing their contents in further abbreviated form to a binary data file, K3S.dat. The writing functions keep track of key indexing information and write this to an index file, K3S.ind. Functions to read from these files are already installed, so the process is completed by copying these two files to the standard data directory in the Magma libraries.
We now go through the process in detail.
Create a sequence containing all K3 surfaces of genus g≥ - 1; restrict to those with singular rank at most r, if given as an argument, or having baskets in the sequence B of baskets, if given as an argument.The return sequence is ordered according to the natural numerical order on the coefficients of Hilbert series. Analysis of projections of Types I and II is made to modify weights of K3 surfaces, and any inconsistencies between different predictions of weights coming from different projections are reported.
A record in K3 record format that contains a subset of the data associated to the K3 surface X from which all attributes of X can be computed.
The K3 surface with the same data as that of the record x in K3 record format.
Write the K3 surfaces in the sequence Q to the file with name given by the string F. The resulting file F is a text file containing Magma code which, when loaded into a Magma session, generates a sequence called data of records in K3 record format that corresponds to Q.
With the data for the K3 database saved as a series of files "k3data-1", "k3data0" and so on, the command load "writek3db.m"; (or load "PATH/writek3db.m";) loads them in turn, writes the two binary files and then deletes the data from the Magma session. Magma must be running in the directory containing all the data files "k3data ... ".
In normal Magma use, even though the data in the K3 database is in coded form (as a tuple, in fact), when returned to the user it is expressed as a K3 surface. Of course, this final translation step takes a little time, insignificant in most use, but very significant when searching through the whole database. So there are functions to access the raw data, and then to translate it into a K3 surface. The search intrinsics installed in the Magma packages use these functions, as should any new searches that need only modest increase in speed.
The i-th element of the K3 database D expressed as a tuple of data (or the i-th element whose Hilbert series has coefficients of ti given by the integers in the sequence Q, which may have length at most 5).
The K3 surface with the same data as that of the tuple x that is in the raw K3 database format.
Here we explain in general terms how to write new databases of polarised varieties. We give complete instructions for writing the data and index files, but are more sketchy on the other steps: you will have to assemble the data, write translation functions and write any cosmetic wrapping functions for yourself.
Step 1: Prepare the directory. Make a new directory, `NewDB' say, and copy the files data_spec.m, write.m, init_info.m, write_tools.m, write_func.m, create_ind_func.m into NewDB from the Magma package directories. Of these files, the first two will have to be edited to conform to the required database, while the remaining four are common to all databases.
Step 2: Decide record format. Edit the file data_spec.m. This determines which data is stored, and places unbreakable restrictions on that data. In particular, the choice of up to 5 indexing parameters is made here. Write intrinsics that translate between the data in its original representation and in its record representation.
Step 3: Update the writing functions. Edit the file write.m.
Step 4: Collect the data. Write all required data as records in one or more files. It is essential that the data is written to these files so that it can be read into a single Magma session in increasing order (with respect to the chosen indexes).
Step 5: Build the binary data and index files.
Step 6: Move the binaries to the data libraries.
Step 7: Final cosmetics. Write as Magma package code any cosmetic wrappers or search routines that are to be used with the new database. Document these intrinsics.