Corrections in simulation
1. Preparing samples :
New script get_samples.sh was created for preparing samples :
nohup get_samples.sh /disk03/results/fits/20060527/
1 > out 2>&1 &
It uses new program checksample
which checks if sample is ok - single star on sample, single local
maximum in cluster, star in center of sample etc, etc ..
2. Putting samples
- CONFIRMATION
ON NEXT REJECTING TO MUCH :
Here there was change in re-put ( confirmation on next algorithm )
before new samples was taken ( randomly ) and now same same as
previously is used. It is because of the fact that in case of new
sample it can have maximum in different pixel causing confirmation on
next to reject many samples !!! This causes error in efficiency
determination.
Also logging of re-put sample ( regenevents.log ) was corrected, max
laplace value is also logged, positions are in agreement with those
from genevents.log file.
It is also possible to save image with put sample.
Tests here :
heplx48:/disk03/results/msok/simul/ccdsingle/20060527
To sa kiepskie
dane - bo z pixel shiftem , ale da sie zyc do testow softu sa ok,
natomiast ostateczne testy mozna zrobic na tych danych : 20060519 ,
20060520, 20060521
bo na nich nie
ma pixel shifta bo byly robione na starym pi2
Notes from this changes :
- 1/
poprawki w skrypcie wycinajacym - checksample dodac zeby mozna bylo
tylko ladnych sampli uzywac
a gdyby
w logu sample_0.log zapisywalo sie oprocz pozycji max value +
max
laplace , a go sampler_0.log - reput position i tez max - dorobic to
moze
pozowli do czegos dojsc !!!
cos nie tak z tym odrzucaniem na nastepnej -
za duzo ich odpada !
CCD_SAVE_IMAGE_WITH_SAMPLE=1
to moze
byc kwestia zlego wklejenia na nastepnej !!! - przesuniecie !
to
wyjdzie z obrazkow !!!
OPISAC
:
nadal
cos nie tak 41% - ale duzo odpada na Confirmation on next
1199 971 - pozycja wklejenia oznacza tyle ze w
tym miejscu bedzie
maximum sample , bo potem jest robione :
x0 = (x0 - OtherImage.m_MaxX);
y0 = (y0 - OtherImage.m_MaxY);
i to jest chyba inaczej w RePut !!!
Sprawdzic na obrazku z wklejonym !!!
czyli
w w pliku genevents_0.log jest zapisywany max_pixel sampla - putanie
co
jest w regen.log ???
Dodac w
ccd_matrix.cpp:809 - zeby najpierw sie laplace liczyl i max value
tez
sie zapisywal do genevents.log !!!
Moze
to byc to ze sample sa troszke inne !!! i OtherImage.m_MaxX
sie rozni przez cos max point jest troche
obok, moze sprawdzic
czy
jak ten sam sample bedzie wklejany to bedzie lepiej ???
Zapamietac pos w CImageCreator::GetSampleObject i wkleic ten sam obiekt
!
Po poprawkach we wklejaniu sampli efektywnosc :
cd
heplx48:/disk03/results/msok/simul/ccdsingle/20060527/RESULTS/reput_same
pieffbkg :
--------- Event Report ---------
Gen# = 978 (978)
GenIdent# = 552
Eff = 0.56
Bkg = 648
--------------------------------
After testing Tv ( = 3 and =4 ) :
Tv=4 :
--------- Event Report ---------
Gen# = 978 (978)
GenIdent# = 622
Eff = 0.64
Bkg
= 3540
--------------------------------
- Tv
SEEMED TO REJECT TO MUCH , BUT ...
It looked from running :
calc_backgr\!
Events/sample_event_rates_ccd0.txt
that Tv cut rejected a lot of events, but it seems that it only looks
like this because in case Tn rejected event and there is another star
nearby ( distance <= 10 pixels ) than it passes
Tn but fails Tv and it seems that event was rejected by Tv. To test
this I changed 10 pixels to 2 by setting :
CCD_MC_GEN_IDENT_REDIAL=2
After such change the rejection rates are : Tn=118/9278= 12% ,
Tv=98/978 = 10% - this is more resonable !!!
I prepare new samples requiring MaxPixelValue>=500 so that no
of them was rejected by Tn - just to check
Notes ( in polish ) :
eff - sample
odpadaja na Tv - czy tyle jest gwiazd czy cos - dlaczego
tyle sampli
odpada na Tv ???
Cos jakby nie
tak z tym LapPrev dziwne wartosci sie zapisuja a mimo to
odrzucone trzeba
sie wdebugowac czy te wartosci maja jakis sens ...
czy cos sie
zmienilo ze tyle Tv odrzuca , to jest jakies dziwne ...
- IfMore
- rejects a lot of samples ????
It also seemed that IfMore rejects a lot of samples - but
this was only bug , there is anti-hotpixel cut checking average of
previous images in checked pixel and this cut
rejected a lot , but it was counted in
Events/sample_event_rates_ccd0.txt log file so it seemed
that it is rejected by IfMore , currently I
turned off this cut by setting :
CCD_CHECK_PREV_OF_MAX_PIXEL=0
And efficiency is ~65% now
WARNING
: loging of number of events rejected due to anti-hotpixel cut
should be added in log file sample_event_rates_ccd0.txt l
- StarCut
- rejects to much
First of all Hipparcos check find stars with (ra,dec)=(0,0) this
happens when event was rejected and has (ra,dec)=(0,0) it is rejected
then and makes mess in log file verifiedevents_0.log
cd_analyse.cpp
Row 11057 :
// adding
HIPPACOS stars to list :
nBigStars =
gStarCatDefault.getStarListHIP( evt1.m_AstroCoord.RA,
evt1.m_A
AstroAngle::arcsec2rad(gCCDParams.m_fBigS
bigStarList, TRUE, FALSE );
this can return stars with (ra,dec)=(0,0) - probably they have
missing coordinates !!!
This
must be corrected !!!
Radius of checking nearby stars is to big it is = 150 arcsec !!! ( ~4
pixels ) while in cataloging it is only 120 arcsec
WARNING
: it must be changed to 120-100 arcsec ( paramter :
CCD_STAR_REJ_RADIUS_IN_SEC=120 )
Zapiski :
TESTOWAC : poprawka :
ccd_analyse.cpp - for(int i=0;i<bigStarList.size();i++){
CCatalogStar& star =
bigStarList[i];
dodac : if( star.ra!=0
|| star.dec!=0 )
dlaczego tylko te BIG_STAR
sie lapia puste ???
To z Hipparcora takie kwiatki
ze ra,dec=0,0
3. Paramtery
Okazuje sie ze teraz duzo odpada na Tv - czyli trzeba chyba zmienic (
bylo Tv=2 ) ale trzeba chyba zwiekszyc, moze i przywrocic laplace=g54
???
Bo wstepne testy LWP wykazaly ze to niby najlepszy byl laplace=12 ale
moze jednak jeszcze to przetestuje , planowane testy :
laplace = 4 , 12
Tn = 4 - 10
Tv = 1 - 4