The headcat catalogue stopped being generated in 2007. I found it wasn't possible to use the routine mk_head_cat to generate a new catalogue file for 2007, so I modified the code.
I have a routine make_pry_head_cat.pro which I'm currently keeping in ~/test/cds. I've ftp'ed this over to solar in the ~/cds_head_cat directory.
To generate a new headcat file (for an entire year) do the following...
First use xcat and find the prog_num values for the start and end of
the year. Suppose these are 31000 and 35000, respectively. Now log on
to RAL and start up IDL:
> cd cds_head_cat
Now execute the following commands:
cidl> f = find_files('s*','$CDS_FITS_DATA')
cidl> n = sort(f)
cidl> f = f(n)
'f' is a list of every CDS file ordered according to the prog_num value. Try printing out a few elements of 'f' in order to find out the rough range in which files 31000 to 35000 occur. This gives indices i_start and i_end.
Remaining in cidl, now do the following:
cidl> make_pry_head_cat, year=year, ystart=i_start, yend=i_end
Where 'year' is the year for which you're interested. After 1-2 hours you should find the headcat file for this year has been created in the cds_head_cat directory.
Bring the headcat file back to NRL and store it in the directory ~/cds_head_cat.
The effect of the SOHO roll is best explained in terms of the CDS synoptic...
Normally the synoptic begins at the north pole, where CDS rasters left-to-right. It then moves to the next lowest position and performs another left-to-right raster, etc.
When SOHO is rolled, the CDS synoptic still starts at the north pole, but the north pole is now positioned at the bottom of the Sun, as viewed by CDS. If we consider how the rasters appear on a Sun that is in its normal orientation, then CDS still performs the synoptic in the correct order (north-to-south). However, the rasters have been performed right-to-left instead of left-to-right.
For a particular CDS data-set stored in a qlds, the value of the SOHO roll angle is obtained by doing:
For data analysis, the window returned by
IDL> dat=gt_windata(a, 0)
will be inverted in both the X and Y dimensions when SOHO is rolled. Using the /invert keyword will invert the array in X and Y, but only if the SOHO roll angle is 180 degrees. This is therefore the best option if you want a spatially corrected array.
The recommended procedure is to create an image in a specific line with nis_quicklook and then use this image to select a pixel mask. With this pixel mask, an average spectrum is created with full_spec_return. The key points to note are:
The IDL map software does not seem to take account of the SOHO roll.
These have values for each data window and are stored in qlds.detdesc.origin and qlds.detdesc.spacing. For rolled data, origin gives the coordinates of the top-left corner of the corrected image; spacing will have negative values for the X and Y directions for rolled data.
A typical sequence of commands is:
IDL> list=vso_search('6-jun-1996 07:00','6-jun-1996 24:00',inst='cds')
This downloads both level-0 and level-1 files and I haven't worked out to filter out the level-1 files, so I just delete the *l1.fits when I'm done.
I store the CDS data in /Volumes/disk1/soho/cds.
From cross-correlating Mg IX and Mg X images in the post-loss period, it was shown that there is a spatial offset between NIS1 and NIS2. Basically, if rasters obtained from Mg IX and Mg X are compared, the Mg IX image needs to be shifted up by a few pixels in order to match Mg X.
The size of the offset varies with Y-position of the Sun, as demonstrated from the synoptic sequence. At the north pole, the offset is about 7 pixels, while at the south pole it is about 2.5 pixels.
The routine gt_nis_alignment gives the offset between the two channels:
IDL> gt_nis_alignment, qlds, x, y
where x and y are given in arcsec (not pixels)
What happens during the SOHO roll? gt_nis_alignment correctly handles this case.
The CDS 'as-run' databases are stored in
There are a set of database commands that allow these databases to be searched, and these commands are described in CDS Software Note #10.