Ricerca di segnali periodici

Al primo calcolatore sono state assegnate 9 righe con 24 DM step cadauno (§3.4.1). Poiché ogni DM step produce un file (con estensione dat) avremo, complessivamente, 216 file. In ognuno di essi, cioè per fissato valore della DM applicata alla serie temporale, dobbiamo andare alla ricerca di segnali periodici (§ 2.5).

A tal fine useremo, in primo luogo, il task realfft, che ci permetterà di spostarci nel dominio di Fourier. Esso, difatti, si occupa di produrre altrettanti file (con estensione fft) quanti sono i dat. Successivamente, tramite il comando zapbirds, elimineremo i picchi dello spettro di potenza corrispondente ai segnali periodici a DM = 0 individuati precedentemente.

Infine useremo il task accelsearch, per la ricerca vera e propria di segnali periodici. Esso sfrutta la tecnica dell’interbinning, vista in § 2.5.2, per arginare i problemi derivanti dalla discretizzazione dei dati. Al comando dovremo assegnare le opzioni che concernono un’eventuale ricerca di sistemi binari ed il numero di armoniche da prendere in considerazione, di norma pari ad una potenza di 2. Nel nostro caso, per gli argomenti trattati nel §2.5.3, ci siamo limitati a considerare le prime 8 armoniche perché, analizzando dei GC, ci aspettiamo di trovare una quantità rilevante di MSP, che richiedono una somma armonica meno dispendiosa rispetto alle pulsar ordinarie. Il tempo computazionale richiesto per l’operazione della somma armonica, infatti, raddoppia all’aumentare dell’esponente, cioè tcalc(2n+1) ' 2tcalc(2n). Per quanto

concerne l’altro parametro, quello che correggere per l’effetto Doppler orbitale, si è scelto uno “zmax” pari a 200 per entrambi gli ammassi (ovvero il massimo valore che può assumere Ndrif t, trovato nella (2.23) del paragrafo 2.6.1). In questo caso il

tempo dell’elaborazione aumenta linearmente al crescere dello zmax. Per la scelta dello zmax ci si è avvalsi dei valori caratteristici usati in letteratura per questo tipo di ricerca, che permette, in generale, di coprire un range di accelerazioni sensato ed avere un tempo di calcolo ragionevole.

Qui, prima di procedere alla ricerca di segnali periodici (con accelsearch), ci siamo spostati nel dominio delle frequenze (con realfft). Stiamo adottando, quindi, i concetti visti nel paragrafo2.6.1, ma seguendo la logica del diagramma di flusso posto nella parte destra di figura2.13(Ndrif t, in questo contesto, è da intendersi come

il numero di bin di Fourier in cui un segnale modulato da un’orbita si sparpaglia), ovvero applichiamo una sola trasformata di Fourier per ogni DM step. Questo, come abbiamo visto, ci consente di ridurre il numero complessivo di FFT e, di conseguenza, il tempo di calcolo.

Nel paragrafo conclusivo dello scorso capitolo (§2.6), abbiamo presentato 4 metodi atti alla ricerca di pulsar in sistemi binari. La tecnica del ricampionamento (§2.6.1),

che opera nel dominio dei tempi, è stata subito scartata poiché, come spiegato in §2.6.2, computazionalmente gravosa. Si è optato, dunque, per le tecniche che lavorano nel dominio della frequenza e tra queste si è preferito il metodo della correlazione. Giustifichiamo la scelta. Il metodo della correlazione è il più esatto e largamente diffuso, ma anche il più arduo da implementare; lo stack/slide è il più rapido ma il meno preciso; il metodo della modulazione di fase, oltre ad essere impiegato di rado, è più efficiente tanto maggiore è la durata dell’osservazione o meglio, quante più orbite essa contiene. Le osservazioni di NGC 6388 e NGC 5946 hanno, rispettivamente, una durata di circa 4.6 h e 8.3 h. Esse non sono sufficientemente lunghe, soprattutto per NGC 6388, da consentire l’applicazione dell’ultimo metodo, a meno di non cercare sistemi binari esotici estremamente stretti.

Problemi di. . . memoria

La durata delle due osservazioni, comunque, è sufficientemente lunga da produrre file di grosse dimensioni. Per NGC 6388 abbiamo quasi 20 Gbyte e per NGC 5946,

2 4 6 8 10 12 14 16 5 10 15 tsamp nchan

Figura 3.9: I punti blu e marroni rappresentano un file dat che de-disperde la serie temporale prima e dopo la “diagonale” della DM (linea verde tratteggiata). Maggiori dettagli nel testo. dato che ha un’esposizione

pressoché doppia, stesso nu- mero di canali e simile fre- quenza di campionamento, pressappoco 40 Gbyte.

Le dimensioni del file, di- fatti, dipendono dalle dimen- sioni della matrice nchan ×

tsamp (fig. 3.9), che diventa

una matrice 3-dimensionale se si dispone di informazioni sulla polarizzazione (nel no- stro caso, come si vede dalla figura 3.2, avevamo diretta- mente l’intensità totale). A sua volta il file dell’osserva- zione produce una moltitudi- ne (ndat= rtotnδDM = 1992)

di file secondari come i dat e gli fft (questi ultimi sono tuttavia temporanei), i quali occupano circa mezzo Gbyte

di memoria a testa. Sempre in figura3.9 (notare la somiglianza con il grafico 2.3 a pagina 46) sono evidenziate le coordinate (in blu) di una serie temporale de-dispersa ad una certa DM: essi rappresentano i punti salvati in ogni file dat. Possiamo dire, in altre parole, che se l’osservazione in toto può essere pensata come una matrice di dati, il singolo dat rappresenta soltanto un vettore. Da qui risulta ovvia la disparità di dimensioni tra il dat e il file dell’osservazione. Oltre a ciò, come detto nei prgg.3.4

e 2.4.1, il raggruppamento dei campionamenti temporali cambia al crescere della

DM: prima della “diagonale” della DM (linea verde tratteggiata) abbiamo un punto blu per ogni tsamp, dopo, a causa dell’incremento di δDM, troviamo, ad esempio,

una coordinata marrone ogni tre tsamp. Nella colonna DownSamp di figura 3.6

avviene una situazione analoga: vediamo, infatti, che i dat presenti nelle ultime due righe di comando hanno un campionamento temporale dimezzato. Tutto ciò riduce ulteriormente le dimensioni dei dat e, a sua volta, dei fft.

Dunque se i 10 scratch hanno uno spazio disco che si aggira sui 200 Gbyte e, come detto all’inizio di questo sotto-paragrafo, se ognuno di essi riceve circa 200 file dat, si dovrà aver particolare cura dello spazio disco nel processo di riduzione. Per le questioni riguardanti questo aspetto si veda l’appendiceB.2.1, dove il discorso sarà reso più comprensibile grazie alla presenza del codice stesso.