Re: Mag compensation and the database

["Gutzwiller, Michael" <mgutzwiller@lanvision.com>]

Chris wrote:

>If I could request some changes then:
>
>1) At least put the filter name in the header. Currently one must
>know what filter is on which camera at each site. Just a
># Filter = 'v'
>whould do it.
>

The new version already does this. (I needed it for the flat
compensation program!)

>2) If you want to do more, copy the entire FITS header into each
>output file. This should do #1 above as I think the filter must be
>in the FITS header, if not we need to add it. Possably a copied
>fits line could look like
># FITS = "<the copyed line>"
>
>It would be best if you would apply an astrometric corection to the
>WCS lines in the FITS header. I want to store a "bounding box"
>for each frame so we can ask "Did TASS _look_ there?" type
>questions. I think the ability to say "Four cames were looking
>but none saw the event" is importent but I'll ned good WCS from
>the FITS headers


These are somewhat tied together. The WCS is certainly calculated and it
should be put into the output FITS file that you can optionally produce.
I will make sure it does and the corrected FITS header will be included
in the star list output.

>3) Correct me if I'm wrong, but I think we need to back out any
>mag adjustment before storing the data. I think Arne wants an
>instrumental mag derive only from the ADU values and some assumed
>zero poiint. He want to compute a transform, once per night per
>site that is based on observed Landolt standards. (Ask Arne about
>this. I am only trying to remember and could have missed something)

If we want data with no magnitude adjustment in the database then the
option must either be turned off in star or the import program will need
to remove the adjustment.

>4) what ever is stored in the database must apply to the Mk IV
>system as well as the Mk III and possibly some future system too.
>This is not hard to do if we follow a rule that says each record
>will describe only the observed object. We keep data describbing
>the observer and camera in another table.
>
>5) I gues the above boils down to this: What I'd like to store is
>the instrumental magnitude for each star _and_ a transform. The
>transform would applay to one site for a specified time period,
>nominally one night. Transforms to be stored as a 3x3 or 4x4
>matrix, followed by site_ID and JD_start, JD_end. Hwo to compute
>the matrix and what to accept as "imstrumental magnitude" I'll
>leave to others But I don't want to store both "mag" and
>"adjustment" for each star. I think computataion of an
>instrumental belongs outside of the database software.


This is a nice, general solution that could be adapted to
non-photometric nights by just squeezing down on the JD limits.

>Does this address your last question? I gues what I would like
>to do is use any "magnitude bias" to dianose the flat, then
>fix the flat and reprocess the data. Continue untill the bias
>is gone. Now you have instrumental magnitudes. Would this work


This may be the best way to approach the problem. Instead of
trying to compensate for a flat problem in the database, use the
flat compensation program to fix the flat vector then reprocess the data
with a better flat. I like it!

>6) What kind of magnitude bias are you seeing in the data?
>and can you be sure it is due to flat fielding?
>
It really varies with the camera. Some show a parabolic shape with
the end points about 0.05 to 0.10 mags above the minimum, some show
minor fluctuations, others show a large slope with a difference of 0.25
mags from one side to the other. Glenn and I are trying to see if the
shape and values are consistent from one night to the next.

>7) File formats.
>My program looks at the last # comment above the data to
>determine file type. It compresses white space before looking
>so it only cares about the order of the column names. It also
>scans the head for lines it understands and ignores the others.
>So adding a header line is OK as is changing the order. A change
>in spelling will chause it to be ignored

I depend on the spelling too so I won't change it.

>
>If you must add a new column add it after the "mag" column.
>I ignore all those numbers to the right of mag, you can drop
>them and save people a lot of FTP time.

Right now it's positioned after the mag error column.

Mike G.