Background in algorithms for nova and flare identification ( on aver20 database )

1. Bad astrometry

One of reasons for flare and nova events is bad astrometry , it is due to fact that normal stars have bad coordinates and apper in catalog in "new place" imitating nova-like objects
In order to eliminate this I require ast_err<0.3 see here also . It will cause losing of about 6% of images , but this must be done.
Maybe improvements in astrometry are also possible , but in order to have algorithm working correctly it is nesesary to reject such frames with not good astrometry.
May notes on this :

    - przejrzec eventy z nocy 20061016 - 7214 klatke sprawdzic - skad tam tyle
      nowych ??? czy to astrometria zle zbiegla, jak to sprawdzic ?
      x-y-ra-dec tych nowych sprawdzic i czy to sa normalne stale gwiazdy
      sprawdzic jakie ra-dec mialy te same gwiazdy na poprzedniej klatece
      uzyc :
           /pi20/msok/tmp/20061016/
       EXLUDED : 7214,7216,7226,7252,7276

     - cos duzo tych nowych z 20061016 ????
      chyba te chmury, zla astrometria - duzy blad na czasci klatek i
      przez to "nowe" to sa normalne gwiazdy ze zle wyznaczona pozycja
         aver20_2006=> select fl_id_frm,count(*)  from flareevents where
         fl_night=20061016 and fl_type=1 group by fl_id_frm order by fl_id_frm;
         fl_id_frm | count
         -----------+-------
               7207 |    39
               7212 |     3
               7213 |     1
               7214 |  1268 <------------- !!!!
          aver20_2006=> select spathtofile,ast_err from frame where id_frm=7214;
             spathtofile     |  ast_err
         --------------------+------------
           k2a_061016_009.ast | 0.35900916
         (1 row)
              select fl_type,fl_id_frm,fl_good_count,ccdx,ccdy from
                   measurements,flareevents where fl_night=20061016 and fl_type=1 and
                   fl_good_count=1 and id_frm=fl_id_frm and star=fl_star;
             dziwny plot wszystkie sa po jednej stronie CCD !
             dla 7214 - jaki trojkat do x=700 ???


2. Testing on heplx43

In order to test new criterias on night already analysied on pi1 , synchronize found flares from heplx40 by running :

   synch_db.pl -remote_db=aver20_2006 -remote_host=heplx40 -local_db=flare_test -night=20061012 -do_insert -get_all
   synch_flareevents.pl -remote_db=aver20_2006 -remote_host=heplx40 -local_db=flare_test -night=20061012 -do_insert
   find_flares_all_nights.pl -night=20061012 -min_points=30 -db_save -dbname=flare_test -dbhost=localhost -verb -use_all_points  -tycho_db="tycho;host=heplx48.fuw.edu.pl"


this will fill database flare_test@heplx43 with flare events found for night 20061012
Then remove from FlareEvent and run algorithm again :

   

 verify if new criteria works fine

3. Changes in paramters

4. Clouds checking

Clouds checking is possible by checking number of stars on image , it is saved in DB in field istarcount, another field is number of catalog stars on given field ( cat_stars ) and number of
stars matched to catalog stars. It is good to check ratio of image stars to catalog stars expected on this image by checking value istarcount/cat_stars.
Scripts for making star distributions were developed, these are : check_clouds.pl and calc_mean_rms.pl .
I run this scripts on aver20_2006@heplx43, distributions for all observed fields can be seen here it was obtained by running :
          check_clouds.pl -dbname=aver20_2006 -allfields -dbsave
Output file sorted.txt contains average and rms values calculated for all fields. Option -dbsave saves mean and rms to Field_Def table and can be used by algorithms.
Distribution of number of stars on all images in aver20_2006 database was done be running :
         check_clouds.pl -dbname=aver20_2006
It is possible to check single night by running : check_clouds.pl -dbname=aver20_2006 -night=20070219
Plot for night :  20070219
In order to check distribution of istarcount/cat_stars ratio run : check_clouds.pl -dbname=aver20_2006 -night=20070219 -ratio
see plot : 20070219_ratio

Zapiski z tego co robilem :

           DODAC SPRAWDZANIE CHMUR W ALGORYTMACH
          CheckCloudsOnFrame( id_frm, n_sigma );
          CheckClouds( night , n_sigma );
          DODAC PO KATALOGOWANIU : check_clouds.pl -dbname=aver20_2006 -allfields -dbsave
          check_clouds.pl
           calc_mean_rms.pl
          uzyc w skrypcie - lub wypelnic na stale w bazie, mozna i tak
          i tak zrobic chyba ? - to nie zajmuje duzo czasu , zrobienie tego dynamicznie
           check_clouds.pl -dbname=aver20_2006 -allfields -dbsave
           check_clouds.pl -dbname=aver20_2006 -night=20070219 -ratio
           check_clouds.pl -dbname=aver20_2006 -night=20070219
           check_clouds.pl -dbname=aver20_2006 -field=0000-90


Notatki z tego :
       - clouds , dodac ciecie : 16146 / k2a_070214_001.ast
      sprawdzic matched/istarcount - rozklad zobaczyc moze mozna po tym przyciac ?
      bez star_fraction pola - test 20061127new
       show_field_stars_stat! - i wszystko widac
      mozna dorobic takie sprawdzenie - ze sprawdza poprzedni rozklad i jak
      mniej gwiazd niz mean-2*sigma to olewa taka klatke
      Ale tylko pod warunkiem ze jest >=50 klatek  :
      /pi20/msok/badania/cat_stars/PLOTS


5. Moon ( sky background ) checking

Dodalem sprawdzanie poziomu tla na poczatku skryptu wyznacza sie treshold funkcja :
        $tresh_avg_sigma=3;
      max_avg := select calctreshavgiter(0.1,10,$tresh_avg_sigma)

Nastepnie kazda klatka z flara +-1 klatka wprzod i wstecz jest sprawdzana czy ma : avg < max_avg , jesli tak to OK, jak nie to odrzuca przypadek ( ustawia reject flag = 7 )

Zapiski z obmyslania :
        - 20070225 :
          ciecie na avg dodac !!! - nie wszystkie pola sa zle :
             select id_frm,istarcount,avg,rms from frame where idaynight=20070225;
          z dobrych ( avg < 1000 ) nie powinno byc tyle smiecia - SPRAWDZIC !!!
          0840+20 - pole jest dosc ksiezycowe
          czyli sa pola lepsze i gorsze - to jest Ksiezycowe i jest slabe, trzeba
          przemyslec jak je odrzucic - moze jednak trzeba wziasc
          Zrobic rozklad pola avg - moze trzeba uzyc mediane czy cos takiego
          a nie avg - bo moze nie jest to gauss  :
           http://www.postgresql.org/docs/7.3/interactive/functions-aggregate.html
          iteracyjnie - 5 razy az mniej niz 0.1  zmiana
                                                                               
           select avg(avg),sqrt(variance(avg)) as rms from frame where avg>0 and rms>0
           and avg<(677+1182*2);