The ARIGFH project was a major undertaking of typing in and processing as many "old" catalogs as possible (GFH is "Geschichte des Fixsternhimmels", "History of the sky"). Most of the files produced by the project are in proj-data. This is an incredible mess, and the project evidently went nowhere. It seems the best version of the code used is contained in proj-data/roland, whereas the most recent data is in proj-data/s07. There was some provisional internal service running that contained quite a bit information of katkat not available elsewhere. This stuff is now in proj-data/katkat and was used to, e.g. generate the format PDFs. katkat ------ In the context of ARIGFH, many catalogs were manually digitized. These are internally identified using file ids looking like 021/1(477) or A21/R(089); they look this weird because they used to be labels of tape files. Within the DC, this data is exposed through the katkat RD, service arigfh/katkat#q; the source is somewhere in proj-data/katkat. This exposes the digitized files and PDFs containing format information. This was gathered using bin/copyNotArigfh.py and bin/copyArigfh.py and created using bin/makePdf.sh. The data -------- Arigfh's plan was to crossmatch the catalogs with a master catalog. Nobody seems to know how far that went. So, we just gobble up all id files from the catalog directories as we can. There are in data/cats, which in turn was generated by unpacking the files in proj-data/s07/archiv-linux. There may multiple id files since the crossmatch was done in a multi-stage process where stars that failed to match in a first step (result id1.id, failures id1.nid) were reprocessed. The format of the id files can be cleaned from q.rd; they are fortran freeform files with a record length of 34 bytes, which means that xxd -c 42 id1.id lets you conveniently view them. The first eleven records are metadata (a.k.a. "junk") Hot fixes --------- In t0120p10, the id[12].id, an "empty" (mostly 0) record had to be removed from the beginning of the file. t1456p10, the id files have the wrong endianess. I've not fixed that for now. Same thing in t1549p10. And in t2560p10. The nid files ------------- Presumably because all information included in them were intended to be included in the istar fields, the kennxN fields were not included in ARIGFH's original nid files. Without those, however, little can be figured out about the stars. To amend this, we re-ran the crossmatches with a slightly changed toolchain. To avoid having to touch the gruesome code too much, we just filled the padding in the nid files files the kennx arrays. Their new format is now: xstar8(1:14) (14*8=112) # next offset 112 kennx8(1:12) (12*4=48) # next offset 160 xstar4(1:9) (9*4=36) # next offset 196 kennx4(1:6) (6*4=24) # next offset 220 istar4(1:2) (2*4=8) # next offset 228 kennx8(13:14) (2*4=8) # next offset 236 kennx4(7:9) (3*4=12) # next offset 248 12 bytes padding # next offset 260 istar2(1:22) (22*2=44) # next offset 304 16 bytes padding # next offset 320 Check: offsets in the old format 0 xstar8(20) -> 160 160 xstar4(15) -> 220 220 istar4(10) -> 260 260 istar2(30) -> 320 The nid files of this sort corresponding to the last identification run are generated by the new id infrastructure as idfailures.nid, and they are processed by the import_nids data item in q.rd.