Proposta (29-3-95):
Cari amici,
a seguito della proposta che avevo fatto (sotto suggerimento di Viviana)
di fare qualche incontro informale di discussione sull'analisi dati, ho
sentito il parere di qualcuno di voi e la cosa ha preso un po' corpo. L'idea
e' quella di trovare un momento di confronto di esperienze ed idee tra
di noi su argomenti attinenti l'analisi dati (e dintorni). Si potrebbe
vederci una volta al mese, in sedi variabili, davanti a una lavagna e riportare
idee e problemi, non necessariamente degli "addetti classici"
all'analisi dati. Una lista di problemi per i primi incontri potrebbe essere:
- filtri
- cosa e' un evento e quali eventi cercare
- coincidenze cosmici
- analisi dati Louisiana (ce li danno)
- temporizzazione
- problemi DAGA2
- scambio dati con AURIGA
Fatemi sapere idee a proposito.
Saluti Sergio
P.S.: Quello che segue e' un SINTS (single image normal text stereogram). Lo riuscite a vedere ?
Punti proposti (gli asterischi indicano preferenze esprese):
Commenti scritti ricevuti
Caro Sergio, al seminario di analisi dati ho notato che alcune questioni sono rimaste in sospeso, ed in particolare mi interessava il seguente problema:
1) buttare via i periodi di disfunzionamento di una antenna quando si fanno coincidenze con un'altra e' consigliabile o no ? Mi pare di capire che le opinioni siamo discordanti, ma mi piacerebbe capire meglio i termini della questione ( e come e' possibile che ci siano idee cosi' diverse al riguardo).
Inoltre, non credi che sarebbe utile sviscerare con una discussione "dedicata" il problema della definizione di evento e dei suoi parametri? Penso che un obiettivo da porci potrebbe essere anche quello di chiarire bene i limiti entro cui ha senso parlare di certi parametri (sto pensando a quelli relativi alla forma del segnale, per esempio).
Poi, mi piacerebbe chiarirmi bene sul confronto
da matched filter e filtro di Wiener. Mi spiego: dalle parole di Pia o
di Pallotino si deduce che le differenze nel comportamento tra i due filtri
sono da attribuirsi essenzialmente a due fattori:
- il tempo di campionamento diverso
- il modo in cui vengono calcolati gli spettri del rumore (per cui, per
esempio, in periodi di scarsa stazionarieta' "e' meglio" il filtro
di Wiener) E' tutto qui, per cosi' dire ? Voglio dire, sono veramente questi
(e soli) i punti cruciali ?
Prima di tutto vorrei pero' dire che se tutti questi dubbi (come altri che adesso non sono stata a riportare) sono del tutto personali forse non vale la pena usare il tempo di cosi' tanta gente per chiarire le idee ad una sola. Se cosi' non fosse, vorrei, nel caso il SEMAPANDA avesse un seguito, che fosse preparato in modo piu' dialettico... E secondo me un modo per realizzare cio' potrebbe essere il seguente: si decide di discutere un solo argomento per volta. Quindi prima arrivano le domande che tu potresti girare a tutti quelli che possono rispondere, che si preparano dei lucidi con le loro risposte (Se in questo ambito, come e' naturale, salta anche fuori un po' di storia dell'analisi dati nel gruppo, non credo che guasterebbe !). Pertanto io vedo prima una fase "informativa" e poi una discussione. Forse cosi' fa bene anche a chi queste discussioni le ha gia' fatte...
ci chiedevamo se e quando ci sara' il prossimo semapanda. considera questo uno sprone a convocarla
Proposte:
Cari amici, qualcuno mi ha chiesto di organizzare un nuovo semapanda (ricordate il seminario aperto di analisi dati che abbiamo fatto ad aprile ?). Fatemi sapere chi e` interessato alla cosa e quali argomenti vorrebbe discutere. I commenti scritti che ricevero` li mettero' sulla pagina web del semapanda, url
http://www.roma1.infn.it/rog/datanalysis/semapanda.html
dove ho messo qualche commento gia' ricevuto e informazioni essenziali. In questo modo non riempio dischi o annoio chi non e` interessato con lettere circolari. Chi non ha facile accesso a WWW e vuole conoscere comunque i commenti ricevuti, me lo faccia sapere. Saluti Sergio
PS: Notate che FRASCAX (il mio username da 11 anni) non esiste piu' e quindi ora sono solo FRASCA; sono cambiati di conseguenza i miei indirizzi di mail (se avete liste con frascax, per favore cambiatele).
Caro Sergio,
questi sono gli argomenti a cui sarei personalmente interessata:
-modi e procedure di caratterizzazione degli "eventi".
-risoluzione temporale degli eventi(attuale e futura).
-modi, procedure e organizzazione del monitor online dei dati.
Per la data del prossimo seminario, per il momento non ho richieste particolari.
Cari saluti
Lucia
Cari amici, come sapete da oltre un anno sto pensando all'aggiornamento dell'hardware e del software di acquisizione per le nostre antenne.
Questa necessita` di aggiornamento e' dovuta soprattutto alle possibilita` offerte dallo sviluppo della tecnologia e al lievitare (relativo) dei costi di manutenzione.
La mia idea iniziale, come sapete, era quella di prendere un alfa DEC con OpenVMS e sviluppare DAGA2_HF con l'acquisizione a 5 kHz.
Era gia` chiaro allora che OpenVMS stesse declinando, ma data la mole del software sviluppato (oltre 100000 righe Fortran) e il knowhow acquisito, questa era la soluzione ovvia. Inoltre pensavo che le future release di OpenVMS avrebbero ridotto il gap con Unix o almeno consentito un meno traumatico passaggio.
I notevoli problemi che ho incontrato nel trovare una soluzione per l'ADC, uniti a tanti altri per realizzare strumenti di gestione di rete, mi ha fatto capire che la situazione era piu' drammatica del previsto.
Che fare ? Accelerare il porting su Unix ? Questa soluzione, incoraggiata dalle dichiarazioni ufficiali dell'INFN sembrava inevitabile. A questo scopo ho preso un account su una macchina Unix, con Pia abbiamo deciso che la sua futura workstation sarebbe stata un potente alfa con Unix e ho offerto una tesi (non ancora iniziata) per realizzare il porting.
Da un po' mi sono pero` sopravvenute varie
perplessita`:
- Unix non e' affatto unico
- per tanti aspetti e` inferiore a OpenVMS
- e' un ambiente ostico
- con l'affermarsi di Windows NT potrebbe trovarsi anch'esso sul viale
del tramonto.
Che fare ? Migrare verso Windows NT ? Al momento mi sembra la soluzione strategicamente piu' interessante. Cerco di illustrarla in breve.
Windows NT e` sviluppato da Microsoft ed e` un sistema operativo multi-utente e multi-piattaforma (cioe' gira, oltre che sulle CPU x86 Intel e compatibili, sulle DEC Alpha, sulle MIPS e sulle PowerPC). E` stato sviluppato dalla stessa persona che nel '78 sviluppo' VMS (WNT significherebbe Windows New Technology, ma in effetti sono le tre lettere successive a VMS). Il suo punto di forza, oltre ad essere avanzato tecnologicamente, e` la sua integrazione con Windows95. Il che significa che (quasi) tutto il software sviluppato per Windows95 gira su questo sistema operativo, che il 90 % degli sviluppatori di software e hardware del mondo lavorano e pensano per questo ambiente integrato. Gli sviluppi verso un utilizzo tecnico-scientifico e real-time sembrano garantiti. E' questa l'assicurazione che ho avuto dalla Digital e dalle informazioni Microsoft. Vedi sul "Real-Time with Windows NT" alle url
http://www.microsoft.com/BackOffice/techbriefs/tech7100.htm
http://www.microsoft.com/BackOffice/techbriefs/tech7200.htm
Tra l'altro si dice:
"For scientific and manufacturing users, Microsoft has been working with a number of applications and device manufacturers to define a set of Windows interfaces that data acquisition equipment can tie into easily. This effort is referred to as Windows for Science, Engineering and Manufacturing or WINSEM for short."
Se DAGA fosse su questa piattaforma ci sarebbe un ricco ventaglio di possibilita` per l'ADC.
Lavorare in questo ambiente e` molto diverso
da come abbiamo lavorato finora con VMS. A parte la parte di analisi che
continuera` ad essere scritta in Fortran, anche se di diverso dialetto,
il resto va sviluppato con OOP, cioe` programmazione a oggetti, in linguaggio
Visual C++ e Visual Basic, e con l'utilizzo di altri linguaggi come il
Perl. DAGA dovrebbe cambiare architettura diventando tipo client-server:
attualmente i vari programmi che lo compongono girano su un solo calcolatore
e chi vuole vedere i dati si logga su di esso; nella nuova configurazione
i vari pezzi potrebbero girare su calcolatori diversi, con una ben maggiore
flessibilita` e potenza. Per esempio:
- il monitor potrebbe vedere contemporaneamente i dati di piu' antenne
- la stessa acquisizione potrebbe dar luogo a due o piu' analisi parallele
- l'analisi attualmente eseguita col Formatter potrebbe essere eseguita
su piu' calcolatori, ciascuno eseguendo una parte del lavoro e quindi rendendo
praticamente illimitata la potenza di calcolo utilizzabile
- si puo` avere un centro operativo per l'analisi online di piu' antenne
insieme (l'analisi di rete).
Infine questa soluzione sembra attualmente piu` economica e probabilmente lo sara` sempre piu` in futuro, poiche` si basa su hardware e software di grandissima diffusione.
Come procedere ? Ne ho parlato con Pia, Maria
Alessandra e con altri e mi sembra plausibile la seguente strada:
- Pia prende invece della workstation Unix, una WNT, che funzionerebbe
anche da server per la rete locale dei nostri PC, su cui cominciamo a imparare
a lavorare e a capire come ottimizzare le cose
- si prende intanto un'alpha in OpenVMS per fare l'acquisizione veloce
come previsto
- si aggiunge a DAGA2 un programma batch DAGA2_SERVER che permette di sviluppare
tre monitor client che dovrebbero avere simili capacita`, ma che dovrebbero
girare uno in OpenVMS, uno in Windows e uno su WWW (e quindi su McIntosh,
Unix,...)
- si fa il porting di DAGA2 completo sulla macchina di Pia, con l'ausilio
del convertitore che ha realizzato un mio gruppo di Lab II (hanno cosi'
portato SNAG su DOS)
- quando tutto va bene si possono cambiare quando si vuole le macchine
di acquisizione (per gli alpha basta cambiare il sistema operativo)
Che ne pensate ? Fatemi sapere i vostri commenti: se per iscritto li mettero` nelle news del nostro sito WWW; si potrebbe parlarne al semapanda 2 oppure il semapanda 2 potrebbe rimanere virtuale tra le news.
Saluti
Sergio
A me sembra che sia tempo di svincolare le necessita' della acquisizione dati da quelle dell'analisi cosi' come si fa per tutti gli esperimenti.
I programmi di analisi possono essere scritti in maniera tale da funzionare su piu' piattaforme. Si dovrebbe enucleare da DAGA la parte che serve per il processamento dei dati offline. Sono sicuro che se si facesse cio' si potrebbe facilitare di molto la portabilita' del programma sulle varie piattaforme. Cio' ci darebbe una gran dose di flessibilita' perche' non e' facile predire quello che succedera' da qui a qualche anno.
Cio' premesso bisogna dire che a Frascati siamo vincolati da quello che esiste al centro di calcolo. Attualmente esistono 3 clusters : VAX, ALFAVAX (VMS), HP (Unix). La potenza di calcolo e' di alcune migliaia di MIPS ed e' tutta disponibile anche per il gruppo ROG. Infatti per il processamento dei dati di Nautilus e' stato usato il cluster centrale di alfaVAX Non e' previsto supportare Windows NT su macchine Digital. Ne e' previsto supportare per il momento Windows NT a livello di commissione calcolo nazionale su macchine Digital (nel senso dei contratti nazionali software ecc). In Frascati ci potra' essere forse nel futuro un sviluppo verso un altra piattaforme su richiesta degli esperimenti di DAFNE (KLOE/Finuda hanno notevolissime esigenze di calcolo). Ma entrambi gli esperimenti parlano al piu' di un'altra piattaforma UNIX (per es alpha).
Cio' ci vincola fortemente perche' non ha senso per noi come gruppo ROG-Frascati mettersi su una strada che non e' quella del laboratorio, tanto piu' per esigenze che possono essere soddisfatte dalle strutture esistenti.
A titolo personale debbo dirti la mancanza di una politica comune ha portato a ROMA1 al proliferare di piattaforme molto diverse e unicamente di gruppo. Tutto cio' e' molto dispendioso sia in termini economici che umani come e' stato ripetutamente fatto notare in Commissione Calcolo. E il risultato finale e' che tutti i gruppi di ROMA1 si lamentano della mancanza di strumenti di calcolo sufficienti.
Per quanto riguarda la vera e propria acquisizione sono sempre dell'idea che svincolare la parte di vera e propria lettura dell'hardware (ADC ecc) con una scheda CPU che vada su un bus commerciale (VME , VXI ecc) sia la soluzione migliore. Se vuoi come schema di principio e' nel verso di quello che dici tu , come d'altra parte abbiamo discusso nel passato. Ho dubbi pero' che Windows NT sia un vero realtime per il front-end (come non lo e' il VMS ne' UNIX standard). Per cui per il calcolatore di front end andrebbe usato un altro sistema (Lynx o VAXELN o Unix RT ecc. anche qui io mi aggancerei alle scelte degli altri esperimenti). Questi sistemi "ridotti" hanno anche il vantaggio non trascurabile di essere piu' facili da usare di un sistema operativo di uso generale. Su questa strada Giovanni ha incominciato a lavorare usando il KAV30. Il KAV30 e' una ottima scheda ma oramai un po' sorpassata, per cui anche se la cosa funzionasse bene, come io spero, converrebbe nel futuro piu' lontano andare su qualcosa d'altro.
Francesco
Caro Francesco, penso che non sono stato chiaro nell'esporre l'idea sullo sviluppo del sistema DAGA. Attualmente esso gira su una singola macchina con tecniche non piu' adeguate agli attuali sviluppi tecnologici. La proposta e' quella di avere un ambiente piu' flessibile, economico e con prospettive di sviluppo adeguate. Vengo ora ai punti da te rilevati, che ho discusso con Pia.
> A me sembra che sia tempo di svincolare le necessita' della > acquisizione dati da quelle dell'analisi cosi' come si fa per > tutti gli esperimenti.
Non ci e' tanto chiaro cosa intendi; cosa intendi con "acquisizione dati" e "analisi" ? L'analisi in tempo reale e' fondamentale, e lo sara' ancora di piu' con l'acquisizione veloce. L'analisi off-line o e' un raffinamento o e' una verifica. Con l'architettura proposta tra l'altro si possono a basso costo fare piu' analisi online contemporaneamente.
> I programmi di analisi possono essere scritti in maniera tale da > funzionare su piu' piattaforme. Si dovrebbe enucleare da > DAGA la parte che serve per il processamento dei dati offline. > Sono sicuro che se si facesse cio' si potrebbe facilitare di molto > la portabilita' del programma sulle varie piattaforme. Cio' ci darebbe > una gran dose di flessibilita' perche' non e' facile predire quello che > succedera' da qui a qualche anno.
In parte hai ragione, ma in pratica cio' comporta un lavoro notevolmente superiore, soprattutto quando gli upgrade sono continui. Prevediamo di fare dei traduttori per poter far girare la parte di analisi su OpenVMS e Windows NT, anche se potrebbe non essere necessario, se un PC con la stessa potenza di calcolo di una macchina VMS o Unix costa 5 milioni, mentre il "costo" del software (e cioe' di noi) rimane alto.
> Cio' premesso bisogna dire che a Frascati siamo vincolati da > quello che esiste al centro di calcolo... > Cio' ci vincola fortemente perche' non ha senso per noi come gruppo > ROG-Frascati mettersi su una strada che non e' quella del laboratorio, > tanto piu' per esigenze che possono essere soddisfatte dalle strutture > esistenti... > Tutto cio' e' molto dispendioso sia in termini economici che umani come e' > stato ripetutamente fatto notare in Commissione Calcolo.
Questo in effetti e' un punto importante, ma crediamo che non sia drammatico. Cio' perche' il tipo di servizi che sarebbero richiesti centralmente e' piuttosto ridotto. In ogni caso, se riteniamo buona questa scelta possiamo chiedere qualche specie di supporto.
In ogni caso i dati potranno essere analizzati sui vax attualmente esistenti e ci sara' una razionalizzazione dell'uso delle macchine in rete come e' naturale in un ambiente client-server.
Per esempio non occorrera` piu' loggarsi sulla macchina di acquisizione per usare il monitor, ma su un qualsiasi PC, Mac, Vax o HP e con in piu' il vantaggio di poter vedere piu' antenne contemporaneamente (per esempio si potra` fare la somma online tra le uscite di due antenne).
Il modo di realizzare cio' ci e' abbastanza chiaro, e sara' realizzato tramite tre monitor client, uno su VMS, uno su PC e uno su WWW; quello su VMS dovrebbe partire subito ed anche quello su WWW potra' essere realizzato nell'ambito di DAGA2, anche se con vantaggi ridotti rispetto al progetto, dato che l'ambiente VMS e' quello che e`.
Il fatto che Windows NT non sia troppo popolare a Frascati potrebbe anche essere uno stimolo ad implementarlo noi, dato che e' opinione comune che la sua diffusione crescera' e che sia un sistema valido e tecnicamente avanzato. Esistono vari gruppi di sviluppo in ambito accademico per esso.
> Per quanto riguarda la vera e propria acquisizione sono sempre dell'idea che > svincolare la parte di vera e propria lettura dell'hardware (ADC ecc) con una > scheda CPU che vada su un bus commerciale (VME , VXI ecc) sia la soluzione > migliore. Se vuoi come schema di principio e' nel verso di quello > che dici tu , come d'altra parte abbiamo discusso nel passato. > Ho dubbi pero' che Windows NT sia un vero realtime per il front-end > (come non lo e' il VMS ne' UNIX standard). > Per cui per il calcolatore di front end andrebbe usato un altro > sistema (Lynx o VAXELN o Unix RT ecc. anche qui io mi aggancerei alle scelte > degli altri esperimenti). Questi sistemi "ridotti" hanno anche il vantaggio > non trascurabile di essere piu' facili da usare di un sistema operativo > di uso generale.
Come sai le nostre richieste per l'acquisizione non sono molto spinte, ne' possiamo pensare che lo siano in futuro. Comunque la nostra proposta non solo garantisce la separazione tra il o i calcolatori che fanno l'acquisizione e quelli che fanno l'analisi, ma favorisce cio'. Inoltre, come risulta dalle pagine web che avevo citato, sembra che WNT sia un buon sistema anche per il real-time.
Forse e' opportuno che ne parliamo a voce. C'e' la scadenza del 10 novembre per decidere sull'alfa di Pia.
Ciao
Sergio e Pia
Proposta:
Cari amici, dopo oltre un anno di silenzio, proponiamo un incontro sui problemi dell'analisi dati, cioe` il "Semapanda 3".La cosa dovrebbe svolgersi a Roma 1 martedi` 25 marzo, alle 14:30.
Proponiamo i seguenti interventi:
Maria Alessandra : Daga2-HF
Pia : ricerca di periodiche e fondo stocastico con la nuova tecnica FDDB (frequency domain data base)
Sergio : nuove tecniche e linguaggi di programmazione
Se avete altre idee, proposte o problemi, fatecelo sapere.
Saluti
Maria Alessandra, Pia, Sergio