The Lari Method for ISOCAM Data Reduction and Analysis: Trouble-Shooting Archive

!!! PLEASE NOTE THE DISCLAIMER !!!

This web page reports some e-correspondence about ISO Data Reduction
with the LARI Method between Oliver Prouton and Mattia Vaccari on one
side and Carlo Lari on the other one. It's not meant to be a tutorial
of any kind, but may rather be of historical "interest":-)

However, for those who dare read on, here's a small legenda:

DOTTED WHITE = Data
RED = Model
CYAN = Reconstructed Flux (i.e. flux ascribable to potential sources)
GREEN = Stabilization Background
YELLOW = On-Target Flag ("up" during observation, "down" otherwise)
PURPLE = Glitch Flag ("up" when glitch is found, "down" otherwise)

Please see Lari et al. 2001 (MNRAS) and Lari et al. 2003 (ESA-SP 511)
for further explanation!

      14/03/2003, Mattia Vaccari, vaccari@pd.astro.it

** 23 April 2001 **


Oliver Prouton wrote:
We have found what we are pretty sure is a source. Can you confirm that you agree that it is not caused by a series of glitches?



Carlo Lari wrote:
it's a pretty source

Oliver Prouton wrote:
We have tried several times to attempt to better fit the region shown. si
Whenever we re-run the fit it masks out readouts 832 & 833 and places the glitch at 834. Mattia thinks this could be the effect of a glitch in a nearby pixel - do you have any suggestions? Is there a way to avoid that the fit considers glitches from nearby pixels, at least in such cases when there is no clear influence from such glitches?



Carlo Lari wrote:
You have to increase the 'factor' say put factor=500. and you will be isolated from nearby pixels
in rep=3 you have to unmask 834 - i.e. if use liscio.rep=3 also unmask 834 before re-running the fit -
the best glitch masking will be
816 (or 817 and liscio.maskg(m,n,816)=-1
833

Mattia Vaccari wrote:
I think I found a new source, but it looks badly reduced to me. Should I try to remove one or both glitches or do something else?



Carlo Lari wrote:
Clean the source from glitches, especially at the end: maybe you will get an underestimate of the source, but not a huge overestimate as this fit does

Mattia Vaccari wrote:
Ecco, il problema e' precisamente questo: come faccio a capire quanti punti mascherare e/o qual'e' un offset ragionevole, in presenza di un buco cosi' profondo? Mi baso solo sulla linea dei ddata? Ti mando la gif della feature per permetterti di spiegarmi meglio.



Carlo Lari wrote:
E' veramente una mostruosita'! Maskera in modo che l'offset sia ragionevole cioe' fino a che il valore differisce dal background di circa 5 e poni un glitch di circa 2 a questo punto agendo sulla tabella di liscio.glist (vedi istruzioni in elais_pieces_new)

Mattia Vaccari & Oliver Prouton wrote:
Se ci sei ancora, potresti dirci che fare in casi del genere, nei quali non c'e' un punto in cui le cose cominciano ad andare chiaramente male?



Carlo Lari wrote:
non capisco! si tratta di un dev4 alto? non lo vedo : per i dev4 alti dei fare il display dell' intero piece ym=struttura(kk).pare(m,n,6)-10 &yx=struttura(kk).pare(m,n,6)+5 mostra,m,n,liscio,ym=ym,yx=yx,t0=struttura(kk).tti,tf=struttura(kk).ttf se si tratta di una sorgente metti /otf qui ne e' segnata una non centrata ma molto debole direi sotto il livello di .7

Mattia Vaccari wrote:
Ti sembra soddisfacente come riduzione di una sorgente? E in caso negativo, cosa faresti per migliorare il risultato?



Carlo Lari wrote:
si puo' andare anche se penso che il flusso sia sovrastimato come si vede dalla coda un po allta : era un vero fader+sougente metti sempre /otf ! ed usa una scala ordinaria per vedere il fit sul background

Mattia Vaccari wrote:
Siccome sulla mostruosita' di ieri ci siamo rotti la testa per un ora e mezza buona senza risultati, vorrei verificare ancora una volta quello che abbiamo fatto.
liscio.maskg=-1 su tutta la parte con dati > background Aggiungiamo un glitch (con liscio.maskg=1 e liscio.ghlist=2.0) sul primo punto "basso", che nel nostro caso era un punto a circa 1 sotto il background. Aggiunta di qualche (2-3) glitch nella fase di risalita. Ora mi viene un dubbio: devo anche "ammazzare" i glitch (cioe' porre liscio.ghlist=0.7) alti alti che ci sono nel mezzo della feature?
Tra l'altro, stamattina mi sono imbattuto su di una cosa in qualche modo simile a quella che ti ho "proposto" ieri: questa volta appare sul pixel (25,1). Te la mando per verificare le cose anche su questo caso. Ti spedisco una visione d'insieme e un paio di ingrandimenti sulle zone piu', cioe' la feture vera e propria e un fader successivo.









Carlo Lari wrote:
metti un glitch in 228 e in 238 poni liscio.maskg(m,n,220:227)=-1 mis sembra pero' che tu abbia problemi sia prima (liscio.maskg(m,n,208)=1) che dopo (246 ?) metti sempre /otf per i gif che mi fai!

Mattia Vaccari wrote:
Ti spediamo una feature "tipo". C'e' un fader durante il quale il fit non e' granche', ma all'uscita del quale tutto sembra andare bene. Abbiamo provato ad aggiungere un glitch (con scarse speranze, a dir la verita'), ma questo ha semplicemente peggiorato le cose. Mascheriamo? Quanto?



Carlo Lari wrote:
Ci vuole un glitch a 624 . se non basta sposta di uno i due glitch iniziali e maschera il primo valore a 619

Mattia Vaccari wrote:
Ancora sui glitch: in casi come questo glist contiene un glitch molto alto in 1234, che mi sembra essere piu' un effetto del metodo che usiamo per deglitchare che altro. Questo come vedi mi provoca un profondo buco in median(liscio.lisci) Cosa faccio?



Carlo Lari wrote:
Il buco nei median(lisci) non ha nessun effetto pratico sulla riduzione ha effetto tutta quella merdaccia che c'e' in giro ovviamente il dev4 rimane alto! ho il sospetto che si tratti di uno dei pixel in basso a destra. se si puo' ripulire un po' va bene (p.e. la caduta a 1218 ..) altrimenti ponilo in attenzione e poi blanchiamo per la mappa

Mattia Vaccari wrote:
Eccoti qui uno dei casi di punti finali problematici. Che faccio, metto maskg=-1 da 4296 fino alla fine del piece, segnalandolo in Attenzione?



Carlo Lari wrote:
bah! intanto perche' il proglamma non ha messo liscio.maskg(m,n,4300)=-1 ? avrebbe dovuto! comunque fallo tu ! immagino che non accetti un glitch a 4297 come fanno i ddata? un trucco immondo e' quello di sposyate PROVVISORIAMENT E di 1 il struttura(2).ttf blankando il valore a 4300 e sostituendo il datai col ddata poi rimetti il valore vero e fai girare st2 nel piece 3 bisognerebbe comunque modificare il programma restringendo il vincolo solo ai 2 punti finali , ma e' una operazione delicata

Mattia Vaccari wrote:
Ti mando un caso limite. Sotto ai resti di un potente glitch si potrebbe intuire una sorgente, che compare piuttosto forte nei pixel adiacenti. Cosa faccio, uso clean_source ed impongo la sorgente o lascio stare e lascio che siano eventualmente le autosimulazioni a dirmi di andare a riguardare qui?



Carlo Lari wrote:
Non mi sembra un caso limite ma una chiara sorgentina (debole) incasinata da noiosi glitch. puoi fare il clean_source , ma proabilmente ti rimangono i glitch a 454 e 366) quello a a 54 devi eliminarlo e blancare a -1 comunque : una sorgente ta 2 glitch normalmente porta a una divergenza o comunque a una notevole sovrastima

Mattia Vaccari wrote:
Ogni tanto all'inizio del primo piece capita che il livello aumenti lentamente e regolarmente, come dopo un lungo dipper. Siccome spesso il fit incontra difficolta', si aggiunge allora qualche glitch. Succede pero' che il fit assuma quest'aspetto "a dente di sega". Si puo' fare qualcosa per far funzionare le cose senza aggiungere parecchi glitch o lasciare le cose cosi'?



Carlo Lari wrote:
analisi corretta. per non scambiare la normale salita iniziale dovuta alla componente 'breve' con un dipper, il programma parte dal posi(1) per valutare l' offset. nei rari casi in cui invece si ha un dipper profondo all' inizio e l' offset non e' sufficiente la ricetta e': -lanci il bk_off (e le istruzioni successive) con um pare5 inferiore a .1 (pe .08) , poi rilanci tutte le istruzioni con il valore .1 ovviamente devi poi anche porre quali_p(m,n,*)=1

Mattia Vaccari wrote:
La stima di questa sorgente mi sembra un po' alta, che ne pensi? E che cosa ci potrei fare?



Carlo Lari wrote:
Devi togliere il finto glitch finale!

Oliver Prouton wrote:
For the first (huge glitch) I thought of adding a glitch (maybe 2) at discontinuities on the recovery (e.g. 702 or 705). I have tried this - it removes the high levels after the glitch but introduces a false S shaped pattern to the reconstructed level under the glitch. Any suggestions?
The second looked like a weak source after the original fit but... now?





Carlo Lari wrote:
first case: you have first to remove sources after I would try to put glitches at 696 and 705 if the fit will be bad in the first part of this strong fader (too near saturation!) move by 1 the two initial glitches and flag 688 .
second case - a nice faint source : you can put liscio.sourcepos(m,n,p1(ks):p2(ks))=1 for a slightly better fit of the background. it's too faint to be seen in surrounding pixels if centeres. with the autosimulation we will see if it is detected in the second pointing .

*** The End ***