
2005.10.12

  By friday (2005.10.07), I managed to get the update process
  working well, and tested it with some example data to demonstrate
  that the partial update improved speed hugely.  Saturday, I started
  to work on the client/server separation of addstar.  The first step
  was to test out socket communication issues.  I set up a simple
  client/server pair, in which one program listens on a socket while
  the client connects to the socket and sends some command.  I set up
  two autocode functions to send and receive complete structures
  (Send_*, Recv_*) and added these to libautocode.  I have been able
  to demonstrate sending Stars, Image, and Options to the server.

  The next difficulty is in pulling out the command-line and
  configuration options.  My original, somewhat lazy, design over-used
  global variables to pass information between program sections.  This
  needs to be cleaned up, especially if the server needs to have
  multiple threads interacting with the db tables.  

  Of the global variables that get set, some simply carry options on
  how gstars should behave when it loads the data (including the
  header interpretation information).  This can probably stay in the
  globals for now.  Another group are configuration information used
  only by the server-related functions, such as defining the location
  of the database files and their format, etc.  These can also stay as
  global, at least for now.  Another set of variables basically pass
  information from the client to the server on how to behave *this
  time*.  I have defined the AddstarClientOptions structure to carry
  these, and will pass them from the client to the server along with
  the stars and the image data.

  Some outstanding issues:

  sidereal time / latitude

  I am carrying these as globals simply because the image structure
  did not have them.  This is silly: I can define them as part of the
  internal image structure without breaking any of the I/O issues.  

  thiscode

  I have been using this as a static photcode structure.  The
  Send_*/Recv_* mechanisms are better suited to simple structures.  I
  probably need to change this to just the code, and use the lookup
  functions to the full structures where needed.  It can be part of
  the options, and I should re-write functions which use it to accept
  the options as an argument rather than rely on it as a global.

  mosaic

  this stores the coords structure for a needed mosaic.  this should
  be kept, filled as needed by the client, and sent to the server with
  the image.  perhaps it can be moved out of global.

2005.10.06

  I am getting seg faults from find_matches_closest, apparently
  related to the partial Measure load.  They occur when trying to
  realloc secfilt.  I tried to debug using the ohana_allocate stuff,
  but it causes problems because fitsio does not fall under the ohana
  memory system.  This is fairly bad; I should probably deal with that
  issue before pursuing the other stuff.  Do I have to make libfits
  depend on libohana, in which case I should probably split off libdvo
  from libohana.  That is probably not a bad plan in any case...

2005.03.07 : notes related to new version of addstar

- USNO seems to work fine now:

  addstar -region 9.0 12.0 9.0 12.0 -cat usno -p USNO_RED
  addstar -region 9.0 12.0 9.0 12.0 -cat usno -p USNO_BLUE

- 2MASS seems to work as well:

  addstar -region 3.0 12.0 12.0 14.0 -cat 2mass -p 2MASS_J
  addstar -region 3.0 12.0 12.0 14.0 -cat 2mass -p 2MASS_H
  addstar -region 3.0 12.0 12.0 14.0 -cat 2mass -p 2MASS_K

- both of these are somewhat inefficient since they need to search
  through the (larger) USNO/2MASS data files for each output ptolemy
  region file.

- GSC seems to work fine now:

  addstar -region 3.0 12.0 12.0 14.0 -cat gsc 
  (photcode is not needed here since there is only one)

- images seems to work fine now

- general concerns:

  - RA 0,360 boundary is likely to have problems, especially with
    region selection
  - mosaic astrometry concepts still need to be added.

  - average magnitudes are being set incorrectly in addstar (not
    taking account of the zero-points).  I don't really want to apply
    the colors here, but I need to do something, perhaps?

    one option is to only apply the correction for the first
    measurement of an object, unlike the way astrometry works
    currently.  both of these should be updated based on
    relphot/uniphot and eqiuvalent relastro/uniastro independently
    from the addstar step.

