Re: TASS Database, plans and progress.

[Chris Albertson <chris@topdog.pas1.logicon.com>]

aah@nofs.navy.mil wrote:
> 
> Michael replied to Chris' latest ideas about the database, and his reply
> sounds good to me.  Some comments on Michael's comments:
> 
> >  I've worked my way through most (but not all) of the data which
> >Glenn, Tom, Mike G., and the JHU guys have sent in.  The number
> >of entries in the "observ" table (the one containing one entry per
> >measurement of a star) is about 6 million, and there are about
> >2 million distinct entries in the "tass_cat" table.  The largest
> >file in the Postgres data area is 606 MB.

I did the same calculation and figured we'd be out of space real quick.
I had hopped Postrgres would fix the 2GB limit problem, they may in time
but big tables are slow and hard to back up.  Postgres now supports "unions"
so it is easy to query a list of tables "select * from tab1 union select * 
from tab2;" will search two tables at once.

>   Neat.  Lots of data!  I presume the tass_cat table then has many unmatched
> TASS vs. mag16 stars? 

I belive Michael is _not_ using a seeded catalog.

 mag16 has only 2.5M entries, and covers a much wider
> declination range than the current mark III sites.  Are these unmatched
> entries single observations, or multiple detections?

Without looking at the data I would guess between 25% and 50% of the 2M
catalog entries are unmatched single detections.  I am going out on a limb
here.  The numbers I've seen depend on which fraction of the data you
process.  

I'll also guess that if we start with a 2.5M entry seeded catalog and start
processing observations the catalog will grow without limit.
> 
>   Some reasons why astronomers have not used the color transformations:
> >               V = a*v + b*r + c*i
> >               R = d*v + e*r + f*i
> >               I = g*v + h*r + i*i
>   (1) if you do not have the R filter, this reduces to the same transformations
>       as before, so the added complexity is not needed.
>   (2) this assumes a single-valued function.
>   (3) the best transformations are when you use a color that brackets the
>       bandpass in question.  If you have V&R, the (V-R) color is much
>       closer to correct than (R-I) and I bet you don't gain by using the
>       longer lever arm, especially since you add in another error term.
>   (4) A better solution has always been to use quadratic terms to handle
>       second order effects.  I don't recommend it since the TASS filters
>       appear to be pretty close to the standard system.
> Bottom line:  Chris' added complexity might help Tom's 3-band camera with
> no gain for any other mark III site.  The extra terms might be useful for
> the mark IV.  There is no harm in including them outside of the extra
> calculation time,

I figured these "extra" terms would be constant zeroes.  No need to calculate.
The only motivation is finding a way to store _all_ the transfomations in a
tabular type table.  By "all" I mean one band sites, two band, three band and
(later) four band Mk IV sites.  Any other method that treats all of the TASS
cameras the same would work.  I am just trying to keep away from special cases.
Any method that allows a transform to be wriiten one way and apply to all
sites id fine.

 and you might gain by having a generic formula that can
> be used with any of the mark III sites.  I probably would be conservative
> and set c,f,g to zero even for Tom's camera.

As I said above,  I think c,f,g are just place holders so you can store
everything in a nice neat table.  Maybe some other method would work
better.  It would be good if we can settle this by the end of this week.

>   Michael, what do you mean by suggesting that standard stars other than
> Landolt standards might be used?  Be careful here!

I was going to ask about how to handle Mk IV data when it is pointing 
off the equator.  What standards are to be used then?  Do we program the
Mk IV camera to drop down to the equator every few frames? so we observe
a few Landolt stars every night?

> 
> >  It would be convenient to calculate the scatter between the
> >"standard catalog" magnitudes and the transformed TASS magnitudes,
> >after the fit has been made; this gives some indication of the quality...
>   I'd assume the transformation file itself would include these error
> quantities. Since these would be mean transformation errors, they would be
> the same for all stars that night and need not be carried as extra fields
> in the main catalog.

This mean error is computed once per what?  Once per site per night for each
filter? or just once per site per nite?  I assume it is just to delta between
the "true" magnitude and the observed, transformed magnitude averaged over some
group of standards.


I have another pretty basic question.  How do we apply the transform, after
it is computed to the data?  For example I am making a light curve in V band
of a star.  I want to plot the function V = a*v + b*r + c*i over time.  Problem
is I have v-band data but may of may not have I or R data taken at the same
time.  On some days we may have _only_ one band for a given star.  Many times
we may have enough data to compute a transform for a site but not every star
will be covered with multiple filter bands..I think Arne
took the easy way out last time around and only concidered stars for which there
where multiple measurments in two bands on the same night.  There must be some
way to handle this even if it means big error bars on the light curve.

> Arne

-- 
--Chris Albertson

  chris@topdog.logicon.com                Voice:  626-351-0089  X127
  Logicon RDA, Pasadena California          Fax:  626-351-0699