Cataloging Development

Cataloging development

sorry for double language page ...

Contents :
1. ra24 bugfix description
2. wyznaczanie dopuszczalnego bledu astrometrii
3. zabezpiecznenie przed ruchami montazu
4. Bacground sources
5. Skiping bad measurements
6. Scan cataloging
7. Clouds check
8. Astrometry problems
9. Bug near pole still present
10. Normalization correction
11. Bug FrameDup
12. Matching Change
13. Sprawdzanie czy HJD jest OK
14. Katalogowanie singli ze scano w
15. Wysoki poziom tla nieba na poczatku i koncu nocy

1. ra24 bugfix

I noticed the bug in average ra calculation to field Stars.ra , the problem is with stars near ( or even on ) line RA=0 and RA=24 , which are sometimes measured
as ra=23.9999 and sometimes ra=0.0001 , in such case average <ra> can be arbitrary !!!! And in one particular case <ra>=8.4 , this bug was fixed
in all sql functions calculating <ra> , number of points ra<9 and ra>12 is calculated and in case N(ra<9) > 0 AND N(ra>12)>0 , then <ra> must
be calculated in such a way that points with ra<9 are counted as ra+24 and after cacluationg <ra> in case it is >24.then 24 is subtracted.
Corrected functions are :

    ReCalcStarStat                       - checked
    UpdateCatalogRangeFast       - checked
    UpdateCatalogRange             - checked
UpdateCatalog                       - checked
ReCalcStarStatFast                - checked

checked - means that after running given procedure I executed :
          select TestRA();
which compares Stars.ra with value of avg(Measurements.ra) for every star in database - if new version of <ra> caclulation is correct for all stars TestRA()
lists only stars on RA 0<->24 line as avg(ra) for this stars gives bad results and in any other case avg(ra) and Stars.ra should be equal for every stars not on 0<->24 ra line.

I have written procedure for fixing bad points , bad points are assumed those with sigma_ra>1.00 the procedure is FixRA24_Bug , there is also a chance that
due to such badle calculated <ra> some stars are split into different record in Stars table, in order to fix such close stars another procedure must be called : FixCloseStars_ra24_bug(do_fix,min_measure_points).
I have loaded data with old procedure 20041030_old and fixed bad stars, loaded 20041030_new again , and then again with new procedure 20041030_new2 , so
in order to check if new procedure is correct compare ra in database 20041030_new2 with 20041030_old :
       20041030@heplx43
   20041030_old - stara wersja, rozne testy
       20041030_new - stara wersja przepuszona przez poprawiarke
   20041030_new2 - nowa wersja
Also I tested all caclulatin procedures I corrected by running procedure TestRA() , this procedure dumps star if it have ra != <ra> - which means error , in case
only bad (0<->24 line stars ) are listed then calculation was ok.
There is also perl script compare_ra.pl which compares ra in 2 databases ( for example 20041030_old and 20041030_new2 )
All tests were done at heplx43:/pi20/msok/tmp/recalc_test/

New version of Stars.ra calculation seems to be working correctly, so I will now install it on pi1
It is nessesary to create index for faster correction of ra24 bug :
       create index sigma_ra_tmp_index on stars(sigma_ra);
       select count(*) from stars where sigma_ra>1;

   na pi1 :
   aver20_2006=> select count(*) from stars where sigma_ra>1;
   count
   -------
     518
(1 row)

2. Wyznaczenie dopuszczalnego bledu astrometrii

Czasem kiedy sa chmury okazuje sie ze mimo ze astrometria zbiega to z duzym bledem, i wtedy pozycje gwiazd sa zle co powoduje ze moga sie pojawic "pseudo-nowe"
bo istniejaca gwiazda ma wyliczona zla pozycje i wskakuje do bazy jako nowa gwiazda !!!
Trzeba sie przed tym zabezpieczyc , czyli np nie katalogowac klatek o bardzo duzym bledzie astrometrii, zrobilem rozklad bledow astrometrii na klatkach sumowanych po
20 , jest tutaj. Z tego wynika ze ustawiajac prog na ast_err=0.3 tracimy 6% klatek jako zle :

AST_ERR CUT VALUE ( allows only < )	FRACTION OF FRAMES REJECTED
0.25	0.11
0.3	0.066
0.35	0.041
0.4	0.032
0.5	0.025

So cut on 0.3 is quite strict , but maybe really nessesary as too much bad astrometry frames are left
I think I will change current value Max_ast_err=0.5 to 0.3 value
awk command :
awk -v sum=0 -v t=0.3 -v all=0 '{if($1>t){sum++;}all++;}END{print "all# = "all;print "bad# = "sum;print "lost = "sum/all;}' ast_err.txt
badania w : /pi20/msok/badania/catalog/ast_err

Taki sam plot dla scanow widac ze max_ast_err=0.3 jest jeszcze w miare bezpieczna wartoscia, natomiast bez tego ciecia trafiaja sie zle klatki w ktorych gwiazdy maja
wspolrzedne przesuniete nawet o kilka pixeli.

3. Zabezpieczenie przed ruchami montazu

Zdarzyla sie sytuacja - noc 20061017 ( badania w /pi20/msok/tmp/20061017 ) ze pojechalismy jeszcze raz do tego samego pola , oczywiscie nie powtarzajac
idealnie pozycji :

   19.76982459 -30.01792004 1160961600
   k2a_061015_00312.fitc
   RA DEC TIME_UT
   ----------------------------------
   19.76982459 -30.01792004 1160961614
   k2a_061015_00313.fitc
   RA DEC TIME_UT
   ----------------------------------
   19.77267034 -30.00465217 1160961669           <---- id_frm(aver20)=7110
   k2a_061015_00314.fitc
   RA DEC TIME_UT
   ----------------------------------
   k2a_061015_00315.fitc
   19.77288844 -30.00094856 1160961735

Co spowodowalo ze pojawily sie liczne "gwiazdy duchy" wynikajace z posumowania przesunietych klatek, do tej pory limit na przesuniecie byl 0.1 deg - to jest 360 arcsec czyli 10 pixeli ( 6 starych ) w tej chwili zmienilem to exeprymentalnie na 140 arcsec ~= 4 pixele ( opcja -max_shift_arcsec=140 programu pi_red_frame ) i bedziemy patrzec czy jest lepiej.
Dodatkowym zabezpieczeniem , moze byc ograniczenie na roznice w czasie kolejnych klatek jesli >50 sec to cos jest nie tak i traktowac to jako zmiene pozycji

Sprawdzilem rozklad roznic czasow miedzy klatkami , ktory jest widoczny na tym obrazku mozna uznac ze roznica czasow >60 sec miedzy kolejnymi klatkami jest podejrzanie
duza i byc moze oznacza zmiane pozycji, czyli tak dlugie przerwy trzeba by traktowac jako zmiane pozycji.
Na razie nie jest to wykorzystywane, ale byc moze trzeba bedzie takowy warunek dodac. W kazdym razie na pewno przerwa dluzsza niz 300 sec oznaczac musi ze cos jest nie
tak badz zmienia sie pozycja i wymaga przerwanie sumy po 20 i zaczecie nowej sumy.
Bylo troche badan na ten temat zwiazanych z tym ze kilka razy w sumie byly zdjecia tego samego pola lekko przesuniete przez co potem kazda gwiazda miala swojego ducha i
katalogowanie wstawilo wiele "nowych" obiektow, oto luzne zapiski :

          - CZASY : /pi20/msok/badania/catalog/aver20_timediff

        zrobic rozklad czasow pomiedzy klatkami i w usrednaniu jak >300 sec
        nie robic takiej sumy ! Traktowac jakby sie pole zmienilo
            /pi20/msok/tmp/20061015
        ale to tylko 66 sec , bylo !
        Trzeba zmienijszyc dopuszczalna zmiene pozycji ! na to co tutaj bylo, czyli :
            dec = 0.01326787 deg = 47 arcsec
            ra = 153 arcsec
            ra^2+dec^2 = 160 arcsec = 4.5 nowych pixeli !!! czyli od 4 pixeli juz
            trzeba zakladac ze jest zle
        Uzyc nowej opcji : -max_shift_arcsec=140 ( 4 nowe pixele )

       19.76982459 -30.01792004 1160961600
       k2a_061015_00312.fitc
       RA DEC TIME_UT
       ----------------------------------
       19.76982459 -30.01792004 1160961614
       k2a_061015_00313.fitc
       RA DEC TIME_UT
       ----------------------------------
       19.77267034 -30.00465217 1160961669   <---- id_frm=7110
       k2a_061015_00314.fitc
       RA DEC TIME_UT
       ----------------------------------
       k2a_061015_00315.fitc
       19.77288844 -30.00094856 1160961735
         moze flagowac jakos w headerze te klatki przy zmianie pola ?
         ale tu byla zmiana na to samo pole ...

4. Background sources

5. Skiping of bad measurements

There are several criteria on level of cataloging to reject very bad measurements , there are several cuts :

in case in there are strange values of mag=29.99 or <0 - these are rejected on level of reading ast file
stars measured lower then h<25 deg are rejected, except for bright stars ( mag < 5 ) - such stars are badly measured and have low value
skiping of stars which have duplicated measurements on single image ( duplicates in ast file ) , flaging of duplicates is done by function FlagDuplicates ( piaddast2/main.cpp program )
NOTE : there is new version of FlagDuplicates commented out now - it remains single measurements ( the most bright one ) from duplicated measurements of star in ast file

NOTE : it is sometimes astonishing that star disapread and is not present in catalog - this can be due to rejection by the above criteria !

6. Scan cataloging

Okazuje sie ze czasem przy katalogowaniu scanow SELECT FROM STARS zajumuje dlugo >1 godzine , sprawdzilem to i okazuje sie ze tak jest dla pol przy ra=0
kiedy warunek na RA jest rozbity na 2 :
      ( ra>=20.9400494747 AND ra<=24.00 ) or ( ra>=0.00 AND ra<=3.1644382172 )
okazuje sie ze optymalizator ( przynajmniej na pi2 ) nie radzi sobie z takim zapytaniem i trwa to strasznie dlugo , dlatego duzo szybciej jest wykonac 2 zapytania :
      ( ra>=20.9400494747 AND ra<=24.00 )
      ( ra>=0.00 AND ra<=3.1644382172 )
i skleic wyniki !
Zrobilem nastepujacy test ( test_speed! ) :
        #!/bin/bash

        echo "Running select Stars speed started at"
        echo "Simple sql"
        date
        psql scan -U pidb_user -c "SELECT count(*) FROM STARS WHERE dec>=-83.1270159657 AND dec<=-55.4418991978 AND ra>=14.5098946140 AND ra<=20.9544571922 AND             CalcDistRADEC(ra,dec,17.74852653,-70.08084287)<0.32386939    and camid=2"
        date
        echo "Complex sql"
        date
        psql scan -U pidb_user -c "SELECT count(*) FROM STARS WHERE dec>=-82.5875708101 AND dec<=-55.0336252688 AND ( ( ra>=20.9400494747 AND ra<=24.00 ) or ( ra>=0.00                                   AND ra<=3.1644382172 ) ) AND CalcDistRADEC(ra,dec,0.05385639,-69.52630105)<0.32386939    and camid=2"
        date
        echo "Complex sql in 2 steps :"
        date
        psql scan -U pidb_user -c "SELECT count(*) FROM STARS WHERE dec>=-82.5875708101 AND dec<=-55.0336252688 AND ( ra>=20.9400494747 AND ra<=24.00 ) AND                                                 CalcDistRADEC(ra,dec,0.05385639,-69.52630105)<0.32386939    and camid=2"
        psql scan -U pidb_user -c "SELECT count(*) FROM STARS WHERE dec>=-82.5875708101 AND dec<=-55.0336252688 AND ( ra>=0.00 AND ra<=3.1644382172 ) AND                                                     CalcDistRADEC(ra,dec,0.05385639,-69.52630105)<0.32386939    and camid=2"
        date
Oto jego wyniki :

                [pi@pi2 log]$ cat ~/test_speed2.out
                Running select Stars speed started at
                Simple sql
                Fri Nov 3 09:43:22 CLST 2006
                 count
                --------
                 390259
                (1 row)

                Fri Nov 3 10:05:50 CLST 2006
                Complex sql
                Fri Nov 3 10:05:50 CLST 2006
                 count
                --------
                 267777
                (1 row)

                Fri Nov 3 11:16:54 CLST 2006
                Complex sql in 2 steps :
                Fri Nov 3 11:16:54 CLST 2006
                 count
                --------
               159329
                (1 row)

                 count
                   --------
                 108448
                (1 row)

                Fri Nov 3 11:22:30 CLST 2006

Jak widac zlozony SELECT zajmuje 1:10 ( stars#=267777) , natomiast po rozbiciu na 2 selecty wszystko zajelo 6 minut !!!!! ( stars# = 267777 )
Czyli trzeba rozbic na 2 selecty !!!!
Tak ze robi sie select a potem drugi dorzuca wyniki do tego pierwszego

a moze jeszcze dolozyc cluster po ra_dec ? - PRZETESTOWAC !!! - czy przyspiesza selecta
   CLUSTER stars_ra_dec_index ON stars;

Test zmiany :
   heplx43:/pi20/msok/data/20061022/ast1/
   20061023_scan
   20061023_scan2

7. Clouds check

Recently I 've written a script check_clouds! which finds log files cat_ast.out from cataloging of aver20 frames and finds line with CLOUDS_CHECK, parses it
and makes distribution of so called "stars rate" , this plot is basically distribution of ratio :
number of stars on pi image / number of stars on this field in catalog
This can be probably best indicator of clouds or things like that, the distribution should be updated daily and is available here.
Conclusion for now is that frames with r<=1.5 should be rejected as cloudy data.

8. Astrometry problems

bad astrometry near pole xy2ad , take output RA,DEC and calculate ad2xy - gives different result then starting (X0,Y0), example :
/opt/pi/dev/pisys/daq/ndir/data/20061116
w ast jest inny xy niz zwraca ad2xy !
Czyli ta transformacja kolo -90 nie jest za dobra ?
xy2ad i ad2xy daja inny wynik ... :
xy2ad k2a_061116_047.ast 1984.0 33.2
19.620447 -81.278139
ad2xy k2a_061116_047.ast 19.620447 -81.278139
2484.000121 -90.730335
This is probably due to unstable astrometry procedure near pole and requires some correction, maybe I will check this on this example !

9. Bug in near pole stars still present !!!???

It seems that on scan@pi2 database cataloging bug is still present , check for example :

    select findclosestars(18.48368149,-71.42240045,120);

    NOTICE: ----------------------------------------------------
    NOTICE: STAR CAM #POINTS (RA,DEC) MAGNITUDE DISTANCE[arcsec]
    NOTICE: ----------------------------------------------------
    NOTICE: 5031 2 80 (18.483297461125,-71.419703545125) 10.096 11.7438160384428
    NOTICE: 6462576 2 12 (18.4832839108333,-71.4218640816667) 10.1085 7.10729128263187
    NOTICE: 6834723 2 15 (18.4836178673333,-71.4218841906666) 10.0876 2.15689917538161
    NOTICE: 7234983 2 11 (18.4836282245455,-71.4189147454545) 10.0847 12.5819567620566
    NOTICE: 7883895 2 3 (18.4830176133333,-71.4210994533333) 10.0916 12.3445762827518
    NOTICE: 7937180 2 2 (18.483130615,-71.4208748) 10.1457 10.9539529615291
    NOTICE: 8126217 2 1 (18.48385763,-71.41870951) 10.1238 13.6286057125981
    NOTICE: 8314064 2 2 (18.48407068,-71.42080002) 10.1436 8.83342911232199
    NOTICE: 8453120 2 1 (18.48388679,-71.42288559) 10.1997 3.9401215507238
    NOTICE: 8565594 2 1 (18.48298815,-71.41830149) 10.0634 18.975152613498
    NOTICE: 8644488 2 1 (18.4838286,-71.42155632) 10.1205 3.95476897554302
    NOTICE: 8715746 2 2 (18.48387237,-71.42192354) 10.107 3.70562594277407
    NOTICE: 8778586 2 1 (18.48362555,-71.41946121) 10.0998 10.6249445638755
    NOTICE: 8854082 2 1 (18.48420404,-71.41854778) 10.1197 16.5287497853318
    NOTICE: 8905405 2 1 (18.48313345,-71.41833915) 10.1252 17.3976185849177
    NOTICE: 8932761 2 1 (18.48361877,-71.41860443) 10.0228 13.7082127530618
    NOTICE: 9005363 2 1 (18.48346103,-71.42191591) 10.167 4.17469013866126
    NOTICE: 9032992 2 1 (18.48396441,-71.41954327) 10.1603 11.3794885078226
    NOTICE: 9087586 2 1 (18.48318829,-71.41752912) 10.0996 19.4820645001918
    NOTICE: 9141578 2 1 (18.48368149,-71.42240045) 10.1921 0
    NOTICE: 9186494 2 1 (18.48352685,-71.42101781) 10.089 5.64391331903939
    NOTICE: 9229802 2 1 (18.48378693,-71.41756141) 10.109 17.5147549330004
    NOTICE: 2717652 3 46 (18.48328282,-71.42015298) 10.0999 10.6070219843973
    NOTICE: 6380460 3 2 (18.48226862,-71.4186289) 10.225 27.8439082872853
    NOTICE: ----------------------------------------------------
     findclosestars
    ----------------
             24
    (1 row)

which shows many close stars which should be cataloged as a single star !!!!

select frame.id_frm,idaynight,spathtofile from frame,measurements where frame.id_frm=measurements.id_frm and star=9229802 order by id_frm;
select frame.id_frm,idaynight,spathtofile from frame,measurements where frame.id_frm=measurements.id_frm and star=9186494 order by id_frm;
select star,frame.id_frm,idaynight,spathtofile from frame,measurements where frame.id_frm=measurements.id_frm and star in (9229802,9186494,9141578,5031,6462576,6834723,7234983,
7883895, 7937180,8126217,8314064,8453120,8565594,8644488,8715746,8778586,8854082) order by id_frm;

Sciagnalem asty i sa tutaj :
    /pi20/msok/data/pole_bug

pole_bug3=> select spathtofile,star,frame.id_frm,ra,dec,magnitude from measurements,frame where frame.id_frm=measurements.id_frm and star in (5032,940757) order by id_frm;
    spathtofile     | star | id_frm |     ra      |     dec      | magnitude
--------------------+--------+--------+-------------+--------------+-----------
k2a_060523_000.ast |   5032 |      1 | 18.48348027 | -71.42149716 |   10.0319
k2a_060523_001.ast |   5032 |      2 | 18.48327813 | -71.42083612 |    10.127
k2a_060805_002.ast |   5032 |     17 | 18.48353361 | -71.42103258 |   10.0226
k2a_060805_003.ast |   5032 |     18 | 18.48366379 | -71.42252077 |   10.1366
k2a_060806_002.ast | 940757 |     64 | 18.48352497 | -71.42162665 |   10.0868
k2a_060807_002.ast |   5032 |    113 | 18.48308515 | -71.42227475 |   10.1731
k2a_060807_003.ast | 940757 |    114 | 18.48359471 | -71.42226154 |    10.173
k2a_060822_001.ast |   5032 |    165 | 18.48354993 | -71.41767672 |   10.1228
(8 rows)

pole_bug3=>

Testowanie tutaj : /pi20/msok/data/pole_bug/AST/20060806/ast1
zaladowac gwiazdy z /pi20/msok/data/pole_bug/AST/TEST i mozna zaldowac klatki k2a_060806_002.ast i juz jest OK !

Select do sprawdzania :
pole_bug4=> SELECT STARS.* FROM STARS WHERE dec>=-92.8927540729 AND dec<=-64.8205008457 AND ra>=-0.2000000000 AND ra<=24.2000000000 AND CalcDistRADEC(ra,dec,11.28931670,-80.27960443)<0.35386939    and camid=2 and id=5032 ORDER BY dec asc;

Chyba juz cos wiem ;
- jak to jest z tym promieniem ... moze jakies SkyMap-em to sprawdzic
czy to zla astrometria czy naprawde przy biegunie distance miedzy srodkiem
klatki a gwiazda moze byc 36 deg ???!!!
   Bo cos to CalcDistRADEC nie dziala dobrze - za maly promien
   pytanie czy to zla astro czy raczej tak naprade jest ????
   To raczej sa problemy astro przy biegunie - sprawdzic to jakos !
   Przeciez FOV jest 20 deg to nie moze byc 36 !!!!
   Czyli trzeba bedzie przywrocic stara wersje po poprawkach w astro
      k2a_060806_000.ast RA = 11.28931670 DEC = -80.27960443
      k2a_060806_001.ast RA = 15.02512081 DEC = -80.01825670
      k2a_060806_002.ast RA = 18.64506967 DEC = -79.70488413
   To bug u mnie - selecta robi tylko na klatce k2a_060806_000.ast
   a potem juz nie i co ??!!! przez to
   radius=0.323861791 radiana
   i mimo ze re-select nie jest potrzebny - to jest bo tam
   obcialem zadaniem tej odleglosci CalcDistRADEC od srodka klatki !!!
   Bo tam zostawilem tylko te w promeiniu 0.32 rad od RA = 11.28931670 DEC = -80.27960443
   a tu jest nowa klatka i srodek jest w RA = 18.64506967 DEC = -79.70488413
   Ewentualnie mozna sprawdzic czy jakakolwiek gwiazda jest poza promieniem
   poprzedniej selekcji i wtedy robic tez re-select
   Lub nie robic CalcDistRADEC

10. Normalization correction

When cataloging ast files normalization correction is caluclated, it is done by calculating correction of near by stars which are found in star catalog ( $DATADIR/cat/act ) .
This correction is calculaated for every pixel on the chip, it is calculated as average of nearby catalog star correction weighted with the distance ( see here for more details ) .
Example of correction images for scan images from night 20061123 are here.
Two check correction image option -save_corr_file must be added to piaddast2 program call in cataloging script.

11. Bug FrameDup

pojawil sie problem ze jak gwiazda wystapila po raz pierwszy na klatce N , ale miala na niej >=2 pomiary ( blad fotometrii ) , to przez to oba te pomiary byly dodawane
jako oddzielne gwiazdy, czyli bezsensu. To co powinno sie zrobic to albo zrobic jedna gwiazde i oba pomiary dodac do tej jednej, albo zrobic gwiazde , ale
dodac tylko 1 pomiar , a drugi skipnac. Poprawilem to i teraz tylko trzeba mocno potestowac, jest tak ze teraz on szuka gwiazdy do ktorej chce to domatchowac , wsrod
wszystkich gwiazd, a kiedys szukal tylko od tych ktore wczytal z bazy danych !
po drodze wystapil bug w przejsciowej wersji, ktory powodowal ze nie umial znalezc gwiazdy na poczatku listy ! - to zostalo wykryty przy ladowaniu danych 20061027
do bazy new_sort_test
ale nadal wyglada ze cos jest nie tak , po pierwszym zaladowaniu do pole_bug7 , wciaz zostalo jakies 200 przypadkow gwiazd ze cos poblizu nich jest <120 arcsec
( see /pi20/msok/data/20061123/scan/ast1/new2.out i test2.out )
teraz puszczam kolejny test juz po poprawce przy pozycji 0 - laduje 20061123 do pole_bug7 , bedzie plik test3.out

wyniki porownania starego katalogowania (20061027_kbtest) z nowym ( te same dane 20061027 ale baza new_sort_test ) :

	20061027_kbtest	new_sort_test	COMMENT
#stars	178698	178141	Wieksza liczba gwiazd w starej wersji wynika pewnie z tego ze wlasnie to poprawialem, tzn jak gwiazda miala 2 pomiary na klatce i wysapila na niej po raz pierwszy to byla dodawana jako 2 gwiazdy
dups when new	starid=856 starid=874	tez sa dwie gwiazdy ale naprwde sa odlegle o 138 arcsec id=873 id=17832	Generalnie wyglada ze jest OK porownalem wiele gwiazd na wyrywki i obie bazy sa tak samo skatalogowane co prawda musialem wyszukiwac gwiazdy w new_sort_test przez findclosestars bo juz numerki id sie rozjechaly ze wzgledu na to ze poprawilem wlasnie tego buga ze w kbtest jest za duzo gwiazd Ostatecznie porownalem wszystko skryptem compare_cat.pl, wyniki tego porownania sa tutaj : /pi20/msok/data/20061027/new_sort_test/CORR1/compare_cat.out wywolanie : nohup compare_cat.pl -db1=20061027_kbtest -db2=new_sort_test > compare_cat.out 2>&1 &

nowa poprawka w FindInCache - jak sie kilka gwiazd znajdzie to od razu tam wybiera jedna najblizsza
Ostateczna wersja jest taka ze :
- jak gwiazda jest wykryta po raz pierwszy ale od razu >1 na tej samej klatce , to zostawiany jest 1 egzemplarz , a drugi jest wywalany
jeszcze troche luznych zapiskow z moich dzialan i testow
a moze wogole zostawiac te duplikaty zrobic gSkipFrameDups=FALSE i juz !

12. Matching change

matching radius test

            On new objectives matching can be ( and should ) be changed from 120arcsec to 72arcsec , this is due to fact that PIXSCALE=36 and 2 pixles is enough , this implies 72arcsec.
          I tested it - loaded with old matching radius 120 arcsec to new_sort_test2 database and with 72 arcsec to new_sort_test database.
            Comparison of stars in this databases gave :

              compare_cat.pl -db1=new_sort_test2 -db2=new_sort_test > compare_cat.out 2>&1

            A jednak wyglada na to ze 72arcsec to jest za malo przyklad w bazie new_sort_test gwiazda id=130621 130651 130706 130707 zamiast 2 gwiazd o jasnosci 10 i 7 sa
            4 gwiazdy ale ta o jasnosci 7 zostala rozbita na 3 gwiazdy co jest bezsensu
            Okazuje sie ze jednak 72 to jest za malo , to troche dziwne, blad astrometrii jest na poziomie 18 arcsec - polowa pixla, no ale jak widac mimo to 72 to za malo ...

            Zrobilem na bazie z matchowaniem 120 arcsec rozklad maksymalnej odleglosci w measurements do sredniej pozycji gwiazdy ( eps ) . Wskazuje on na to , ze mozna przyjac
            promien matchowania 100 arcsec , minimalnie 80arcsec. Chociaz wlasciwie nie wiem czy dobrze uwzglednia on bliskie gwiazdy ...
            Moze mozna zrobic jakis lepszy plot zeby to sprawdzic ???
            Avg(radius) =
           Posluzl mi do tego sql :
                   nohup psql new_sort_test2 -U pidb_user -c "select (select max(abs(calcdistradec_arcsec(stars.ra,stars.dec,measurements.ra,measurements.dec))) from measurements where star=id) as
                   max_distance from stars" > max_dist.txt 2>&1 &
            Hmm ale ta gorka po prawej >100 to moze byc to czego szukam czyli bliskie gwiazdy !!!
            Zaraz to sprawdze !
            Wybralem gwiazdy ktore maja duza ta maxymalna odleglosc miedzy pomiarami :
                   select id,ra,dec,sqrt((sigma_ra*15*3600)^2+(sigma_dec*3600)^2) as ast_err from stars where (select
                             max(abs(calcdistradec_arcsec(stars.ra,stars.dec,measurements.ra,measurements.dec))) from measurements where star=id)>100 and no_measurements>=10;;
            wyglada na to z one glownie pochodza od paska z otwatej migawki.
            a jeszcze zrobilem rozklad maxymalnej odleglosci miedzy pomiarami , jest on tutaj :

kolejne sprawdzenie to troche inne - nie max(odleglosci od sredniego polozenia gwiazdy) lecz maxymalna odleglosc 2 pomiarow w tej samej gwiezdzie
zrobilem to tez na bazie new_sort_test3 - ktora ma zaladowane duplicaty pojednyczej klatce ( ale to bez sensu ), czyli test zrobilem na bazie new_sort_test
ktora miala promien matchowania 120 arcsec, ten rozklad mowi jak w obrebie tej samej gwiazdy moze sie mocno zmieniac pozycja - tzn gwiazdy
ktore maja to duzo , moze sie okazac , select wygada tak :
   nohup psql new_sort_test2 -U pidb_user -c " select m1.star,max(calcdistradec_arcsec(m1.ra,m1.dec,m2.ra,m2.dec)) from measurements m1,measurements m2 where m1.star=m2.star group
   by m1.star" > max_measure_dist.txt 2>&1 &
i jesst sprytny chociaz wolny ...
Mozna go ewenutualnie zmodyfikowac na taki :
      select m1.star,max(calcdistradec_arcsec(m1.ra,m1.dec,m2.ra,m2.dec)) as max_dist from measurements m1,measurements m2 where m1.star=m2.star group by m1.star having
      max_dist>100;
Ale daje podobne resultaty do odleglosci od sredniego polozenia gwiazdy.
sredni blad polozenia :

            new_sort_test2=> select sqrt((avg(sigma_ra)*15*3600)^2+(avg(sigma_dec)*3600)^2) from stars;
                 sqrt
            ------------------
             62.7528314779976
            (1 row)

            new_sort_test2=>

            sredni rozrzut polozenia gwiazdy ~ 62 arcsec

           Wybor gwiazd o duzym rozrzucie :
                select id,sigma_ra,sigma_dec,ra,dec,sqrt((sigma_ra*15*3600)^2+(sigma_dec*3600)^2) as ast_err from stars where sqrt((sigma_ra*15*3600)^2+(sigma_dec*3600)^2)>62
                       and no_measurements>50;

OSTATECZNY WNIOSEK : zmieniam promien matchowania na 100 arcsec

13. Sprawdzenie HJD czy jest OK

Wnioski ostateczne - jest ok, to co bylo troszke zle to niekonsystencja tzn JD do liczenia HJD bylo brane z klatki srodkowej w sumie po 20 , a UT_TIME bylo z pierwszej
stad jak liczylem HJD na podstawie UT_TIME,RA i DEC na stronie http://www.physics.sfasu.edu/astro/javascript/hjd.html to wychodzilo ciut inne niz to co jest w bazie.
Zapiski z tych testow :

- time_hjd ??? - na www poszukac i porownac z moimi obliczeniami dla gwiazd
   http://www.physics.sfasu.edu/astro/javascript/hjd.html
jakas lekka roznica w jd :
      18h34m48s -11deg43'36''
      aver20_2006=> select ra,dec,time_hjd,ttime_ut from measurements,frame
         where measurements.id_frm=frame.id_frm and star=183939;
           ra      |     dec      |     time_hjd     | ttime_ut
         -------------+--------------+------------------+------------
          18.58008639 | -11.7267289 | 2453993.63152849 | 1158289511

      bash-2.05b$ pidate -jd=1158289511
      Julian day ( unix_time=1158289511 ) = 2453993.62859954

bash-2.05b$ ./date2date -jd2hjd=2453993.62859954,18.58008639,-11.7267289
      hjd( jd=2453993.62859954 ) = 2453993.63022074
      ZGADZA SIE !
      Juz chyba wiem w starych danych to pochodzilo ze srodkowej klatki
      JD - i przez to roznica !!!
      Ale teraz bedzie OK, bo wszystko idzie z 1 sumowanej klatki !

      Jak sie wezmie JD z pliku :
      /data2/results/20060914/k2a_060914_00915.fitc | 2453993.62990741 | 2453993.63112311 | 1158289624
      bash-2.05b$ ./date2date -jd2hjd=2453993.62990741,18.58008639,-11.7267289
      hjd( jd=2453993.62990741 ) = 2453993.63152849
      czyli to co mialo byc - tzn po prostu wczesniej liczyl z JD na
      srodkowej klatce, teraz liczy juz z pierwszej i bedzie sie zgadzac !

http://www.physics.sfasu.edu/astro/javascript/hjd.html
      9/15/2006   3:5:11
      Sun -- RA: 35h 30m   DEC: 3° 8'
      Earth -- RA: 23h 30m   DEC: -3° 8'
      Object -- RA: 278.7°   DEC: -11.726666666666667°
      Earth -- X,Y,Z: 0.990409812348666,-0.12676963447108805,-0.05493508332156047
      Object -- X,Y,Z:
      0.14810375388938565,-0.9678623616606151,-0.20324302439348088
      Light Time: 2.333251257227932 minutes
      Julian Date: 2453993.628599537
      Heliocentric Julian Date: 2453993.63021985

wczesniej bylo zle bo UT_TIME nie bylo z tej samej klatki co JD i przez
   to sie rozjechalo troche , ale malo bo JD bylo ze srodkowej klatki na sumie

14. Katalogowanie singli ze scanow

Katalogowanie singli ze scanow , zmiany :

przywrocilem maxymalne dopuszczalne bledy do astrometrii ( testowalem 1.0 / 0.5 - ale za duzo sie nie robilo astrometrii ) :
export EXTERNAL_AST_ERRF=2.0
export EXTERNAL_AST_ERR=1.0
i dodalem opcje dla piaddast2 : -max_ast_err=2.5 - to powinno byc ok dla klatek pojedynczych ze scanu
OSTATECZNIE (20070101) :
Przywrocone wieksze dopuszczalne bledy astrometrii a w piaddast2 -max_ast_err=3.00 :
- OPISAC co zrobilem -err=1 -errf=2 , oraz to ze -max_ast_err=3.00

cos jest nie tak z piphoto ? jak robie piphoto/astro na jednej klatce to
jest lepiej jak na wielu o co tu chodzi ???
TESTY /pi20/msok/data/20061225/scan/
   run_single_scan_cat! 20061225 /pi20/msok/data/ /pi20/msok/data/SCAN_SINGLES_PIPELINE/ scan_single localhost 0 0 0 0 > out 2>&1
dziwne robie oddzielnie piphoto jednego pliku i jest inny wynik AST_ERR niz
jak zrobilem wiele plikow na raz ???
Cos jest nie tak i trzeba by zrozumiec co
Pliki po piphoto roznia sie w zaleznosci od tego czy duzo plikow na raz
zostalo zrobionych czy tylko 1 - sprawdzic to !
Zrobic tak - zrobic piphoto na 1 pliku a potem na 2 i sprawdzic czy sie
roznia !

   k2a_061225_00317.ast RA,DEC = 7.61110086, -69.89469634
   k2a_061225_00308.ast DEC=-70 - czyli tez blisko bieguna

raczej duzy AST_ERR jest blisko bieguna
Trzeba zmienic na : -err 0.5 -errf 1.0
powinno byc lepiej

Mozna zlagodzic :
piaddast2 - -max_ast_err=1.00

pewnie dlatego tez blad jest taki duzy

15. Cos dziwnego co znalazla Kasia ( black pixel - > hot pixel )

Chodzi o to ze na chipie w tym miejscu jest ewidentnie black pixel - on sie gorzej zachowuje i ma mniejsze wartosci niz w pixlach obok, natomiast po sflatowaniu
okazywalo sie ze stawal sie on hot pixelem. Generalnie na orginanych klatkach jest to black-pixel, ale flat w tym miejscu tez ma mala wartosc F[892][1417] = 0.29 ( przed flipem y=892, x=1417 )
Zbadalem te klatki i tak to wlasnie jest.
Trzeba pamietac o tym ze (x,y) w bazie to jest po flipie, czyli trzeba ogladac klatki po flipie lub patrzec na (x,2048-y) to bedzie ok.
Zapiski :

        - black pixele / hot pixele na scanie - po sredniej i odjeciu darka nadal
        jest black dopiero podzielenie przez flata sprawia ze zrobil sie po prostu jasny !
        ale tylko ten na prawo od czarnego czyli nie (1416,1155) tylko (1417,1155) !

czyli wyglada na to ze na darkach ich nie ma, a sa na zdjeciach , tak jakby mialy za male wzmocnienie

16. Wysoki poziom tla nieba na poczatu i koncu nocy

Wyglada na to ze jakby za wczesnie zaczynamy obserwacje ( h_sun = -10 deg ) i za pozno je konczymy. Moze trzeba to zmienic na h_sun=-12/-13 deg
W tej chwili wykres sredniej wartosci na zdjeciach w funkcji czasu od startu obserwacji wyglada nastepujaco.
Przez to powstaja pseudoflary, ktore trzeba przegladac. Mozna zrobic :

       1/ albo startowac pozniej (h_sun=-12/-13 deg)
       2/ albo wywalac flary gdzie tlo nieba bylo jeszcze za wysokie
       3/ moze miec w bazie wyliaczona wysokosc slonca dla kazdej klatki ???
        + average

czyli albo zaczynac pozniej i nie zbierac danych poki jest tak zle, albo wywalac to na poziomie katalogowania ( bo to przeszkadza tez w innych analizach ) albo
wywalac tylko flary jak tlo jest za wysokie np avg<1000 to OK , a reszta OUT !
Ja bym sie sklanial zeby nie katalogowac klatek z duzym poziomem tla >LIMIT i juz ? Mozna to zapisywac do fitsa i potem sprawdzac lub zapisywac do headera
wysokosc slonca i po niej odrzucac , bo takie klatki przeszkadzaja przy analizie zmiennych pewnie tez !



Notatki i przemyslenia :

        - czy nie za wczesnie startujemy ??? moze przy h_sun=-12 dopiero ?
            Sun position : (20h10m10.94s,-20.08)

        czy pierwsze klatki z nocy nie sa jakies lewe ???
        Dodac zapis sredniego poziomu tla do headera i bazy - pytanie czy
        da sie jakos wykryc ktore sa za jasne, moze za wczesnie zaczynamy
        obserwacje ? zrobic plot z nocy getstat-em !
            for fits in Ls *fitc; do getstat $fits | grep Average; done
        jak sie zapisze do bazy poziom tla Average to mozna odrzucac to
        juz w trakcie analizy , lub zrobic rozklad Aerage dla klatek z nocy
        i odrzucac te z za duzym !
        A moze liczyc wysokosc slonca nad horyzontem i odrzucac te co > -15 ?
        Tlo nieba jest duze o zmierzchu i o swicie trzeba by to chyba jednak
        jakos obslugiwac w tych flarach
           1/ albo startowac pozniej (h_sun=-12/-13 deg)
           2/ albo wywalac flary gdzie tlo nieba bylo jeszcze za wysokie
           3/ moze miec w bazie wyliaczona wysokosc slonca dla kazdej klatki ???
                + average

17. Usuwanie gwiazd z mala liczba pomiarow

Sluzy do tego skrypt clean_bad.sh ( jest procedura sql - CleanBad oraz skrypt clean_bad.sql )
Dziala to tak ze usuwa gwiazdy o <=2 pomiary oraz ktore mialy ostatni wpis do bazy dawniej niz 10 dni temu. Jest tez testowany warunek zeby nie byly to obiekty
przypiete do InterestingObjects ( io_star_k2a lub io_star_k2b ) - ale to moze byc za wolne.
Okazuje sie ze poniewaz wczesniej nie bylo tego warunku na starsze niz 10 dni to zostaly usuniete gwiazdy , a pole io_star_k2a bylo wypelnione wartosciami usunietymi przez
to jak sie gwiazda sciagnela to nie bylo jej w bazie ani jej pomiarow , przyklad :

        baza aver io_id=302818 io_star_k2a= 5860959
         select * from interestingobjects where io_id=302818;

W tej chwili to sie nie powinno zdarzyc, bo jak juz sie sciagnie , a na pi3 sie usunie to nie szkodzi bo juz na heplx40 bedzie i nie zostanie usuniete, a usuwaja sie tylko
stare wiec nie ma szans zeby nie zdarzyla sie sciagnac , a juz sie usunela.
Na razie wylaczylem wogole to usuwanie i wlacze je spowrotem po powrocie
Oto notatki dotyczace tego problemu :

            - brakujaca gwiazda w aver Nova in centeurus - podejrzewam ze bylo tak,
            sciagnela sie stara gwiazda - ale zostala wyczyszczona
            Ale nowe czyszczenie , ktore czysci tylko stare gwiazdy o 1,2 pomiarach
            powinno byc bezpieczniejsze !
           baza aver io_id=302818 io_star_k2a= 5860959

             select * from interestingobjects where io_id=302818;

            update interestingobjects set io_star_k2a=null where io_star_k2a>=0 and
           (select count(*) from stars where id=io_star_k2a)=0;

UWAGA : na potrzeby scan@pi2 powstal inny skrypt clean_scan_db! trzeba by go puszczac co jakis czas, chodzi o to ze na bazie scan nie jest robione przeliczanie
i nie mozna !!!! usuwac po no_measurements bo to nie jest wypelnione, wiec trzeba zliczac rekordy w measurements. Dlatego jest to wolniejsze, ale dziala bo juz testowalem
mozna by to dodac zeby sie robilo raz na jakis czas

18. Padniety CLUSTER

Problemy z padnietym CLUSTREM ( pad pradu badz brak miejsca na dysku ) mozna naprawic ogladajac czasy utworzenia plikow i kasujac te wytworzone przez komende CLUSTER , czasem
jednak to jest trudne, trzeba sie upewniac czy dany plik nie jest potrzebny , robiac :

       psql scan
       select relfilenode from pg_class WHERE relfilenode like '%48868356890%';

Nalezy pamietac zeby szukac w bazie scan lub scan_single

jesli go nie znajduje, to jest duza szansa ze mozna taki plik bezpiecznie usunac.
Ostatnio zastowosowalem jednak inne metode, mianowiscie zrobilem dumpa baz scan i pidb :

    nohup pg_dump pidb > pidb.sql 2>&1 &
    nohup pg_dump scan > pidb.sql 2>&1 &

a nastepnie :
    1/ wylaczyc postgres-a
    2/ mv /data1/pidb/ /data1/pidb_old
3/ mkdir -p /data1/pidb/
4/ wlaczyc postgres-a
    5/ zalozyc baze scan i scan_single
    6/ zaladowac dane do scan
    7/ zaladowac dane do pidb

pozniej trzeba sprawdzic ze wszystko jest OK, i mozna pidb_old usunac. Trwa to na pewno dluzej niz usuwanie plikow , ale chyba jest bezpieczniejsze !
Ostatecznie zrobilem po prostu dumpa calej bazy scan ( pi2:/data2/backup/pidb/scan/20070221/ALL/ ) nalezalo pamietac tez o bazach pidb ( /data2/backup/pidb/pidb/20070221 ) ,
gcvs ( /data2/backup/pidb/gcvs ) i tycho ( /data2/backup/pidb/tycho )
Potem zrobilem jak wyzej , wylaczylem baze , movnalem pidb na pidb_old i zalozylem nowe bazy , ktore nastepnie zaladowalem, baze scan_single calkiem wykasowalem
Dump bazy scan zajmowal 47GB , a bazy pidb 0.7GB
Zapiski z tych operacji :

           OPISAC NA SIECI JAK TO REANIMOWAC + pi2 : jeszcze gcvs i tycho !!!
            pi2:/data1/ - znow cluster padl ....
           testdb.sql - testdb!
           oczyscic scan_single
           odzyskac miejsce na scan - ale jak ???
           /data2/backup/pidb/scan/20070221
            robie pelnego dump-a w :
           scan : /data2/backup/pidb/scan/20070221/ALL/
           pidb : /data1/pidb_old/backup/pidb/
           tak bedzie chyba prosciej i zalozyc baze od nowa !



             aktualny rozmiar bazy scan - 47 GB , pidb - 0.7 GB
             Dorobic : zeby co jakis czas czyscic baze scan_single

Na przyszlosc plan operacji :

dump scan database
dump pidb database
dump gcvs and tycho databases ( or use dumps in pi2:/data2/backup/pidb/ )
turn off postgres
login as root ( or postgres )
cd /data1/
mv pidb pidb_old_20070223
mkdir pidb
chown postgres pidb
chgrp postgres pidb
cp pidb_old/dodb! pidb/
cp -a pidb_old/scripts pidb/
cd pidb/
/etc/init.d/postgres start
./dodb! scan
./dodb! scan_single
./dodb! pidb
./dodb! tycho
./dodb! gcvs
load data to tycho , gcvs, scan and pidb databases
I think it is ok now - enjoy restored database !!!

NOTE : Byc moze nalezy co jakis czas czyscic baze scan_single !!!!

Bo i tak tych danych potrzebuje tylko algorytm do novych na scanach !!!

19. Sprawdzanie chmur - na podstawie liczby gwiazd

See notes here

Statystyki liczby gwiazd per pole robione na heplx40 sa tutaj ( update automatyczny okolo 18:00 czasu WAW - troche trwa )

20. Porownanie innych katalogow do normalizacji ( z gwiazdami odniesienia )

Kasia przygotuje katalog gwiazd stalych = TYCHO2 - GCVS - ASAS
i mozna to przetestowac, do tego celu nalezy uzyc programu pigencat , ktory z pliku tekstowego z gwiazdami robi odpowiedni plik binarny. Przykladowo konwersja
tycho do wersji binarnej :
            tycho2txt!
          pigencat tycho.txt -save=tycho -verb -ra_in_deg
Nastepnie mozna sprawdzac czy jakas gwiazda jest w TYCHO-2 w zadanym promieniu robiac :

          checkstarcat 17.0089 -39.8500 -radius=200 -cat_file=/opt/pi/dev/pisys/daq/ndir/data/cat/tycho -cat=ASAS

Prawdopodonie uzyjemy TYCHO-2 tez na probe jako katalog gwiazd odniesienia, wkrotce mozna bedzie to odjecie uzyc tez STARCONST
Opcje gdzie mozna tego uzyc :

jako gwiazdy odniesienia
astrometria
odrzucanie gwiazd stalych w algorytmach on-line i off-line
zasiewanie katalogow gwiazd

Luzne notatki :
    - pigencat - conversion of Tycho to cat/act structure ...
    tycho2txt!
    pigencat tycho.txt -save=tycho -verb -ra_in_deg
dziala : checkstarcat 17.0089 -39.8500 -radius=200 -cat_file=/opt/pi/dev/pisys/daq/ndir/data/cat/tycho -cat=ASAS
   - w niormalizacji
   - w astro ?
   - dorobic sprawdzanie gwiazd w tycho a nie w act/ - jak to zrobic ???
      Tu potrzebna beda zmiany bo to jest robione przez static variables ...
      Trzeba bedzie to jakos zmienic ... zeby inny katalog mogl byc uzyty
      chyba ze po prostu tutaj bedzie zawsze tycho uzyty ???
      Trzeba to dobrze przemyslec !
      Moze najprosciej bedzie wprowadzic globala do ASAS/cat i TYCHO/cat ?
      Lub ewentualnie oddzielne zestawy funkcji static do ASAS/cat i TYCHO/cat ?
      chyba global bedzie jednak lepszy ...
   - zasiewanie katalogow z TYCHO !!!

     TESTY :
     www : http://grb.fuw.edu.pl/pi0/user/msok/tmp/20070307/SingleEventsHtml/
   nie ma tu za duzo blyskow z powodu chmur i gwiazd , ale cos powinno odpasc
     i dac sie przetestowac !

     Wogole zamienic sprawdzanie gwiazd stalych w tym katalogu a'la ASAS na TYCHO !
     moze jakis limit ze tylko jasniejsze niz 12 mag - zeby jakis flar z 15 -> 9
     nie odrzucil !

21. Ocena zlych klatek

Astrometry error
Zbadalem rozklad ast_err z klatek aver20_2006 ( skrypt show_asterr! ) wynik jest do obejrzenia tutaj : gif ( eps )
Widac ze sa dwa nachylenia i juz na poziomie ast_err=0.25 sie cos zmienia wiec tam mozna by bylo ustawic ciecie , w tej chwilie jest max_ast_err=0.3
Stars shape

     Zbadalem rozklady SHAPE ( kolumna 11 w pliku ast ) dla kilku klatek oto wyniki :
               k2a_070421_010.ast ( klatka brana w czasie ruchu montazu ) : gif eps txt
               k2a_070412_010.ast ( normalna klatka ) : gif eps txt
      oprocz tego ze <shape> jest wiekszy dla 070421_010 to jeszcze jest tam mniej gwiazd
              k2a_070411_010.ast : gif eps txt
              k2a_070411_060.ast : gif eps txt


Tutaj chyba mozna by probowac odrzucac poruszone klateki po srednim <shape> np jesli >0.25 to odrzucamy klatke ( lub przynajmniej przypadki z takiej klatki )
Stars sharp
Rozklady sharp ( kolumna 10 w pliku ast ) :
          k2a_070421_010.ast : gif eps txt
          k2a_070412_010.ast : gif eps txt
          k2a_070411_010.ast : gif eps txt
          k2a_070411_060.ast : gif eps txt

Te nie wygladaja zbyt optymistycznie jesli chodzi o odrzucanie poruszonych klatek