Minute del meeting del 05/12/2017 (last update 15/12/2017 h. 11.45)



Alberto presenta gli ultimi aggiornamenti sul progetto, che e' stato approvato dalla CSN V con una riduzione di budget da parte dei referee in linea con quanto previsto in sede di preventivo. Per quanto riguarda la sede di Padova l'inventariabile e' passato da 8 a 4 kE, che sono insufficienti per qualsiasi acquisto di hardware. Se gli acquisti saranno effettuati alla fine del 2018, sara' tuttavia possibile aggiungere fondi da altre voci per arrivare agli 8-10 kE necessari per l'acquisto di almeno un compute node da aggregare alla Cloud Area Padovana. Alberto segnala poi un interessamento da parte dello IOV, che se si concretizzasse sarebbe di notevole importanza per il consolidamento del progetto.


 


Marco presenta il piano di lavoro del task 1, segnalando che sono gia' state create le mailing list e una wiki per facilitare la gestione e la documentazione dei vari task, nonche' un progetto sulla Cloud Area Padovana dedicato agli utenti di ISOLPHARM_Ag. Il giorno seguente viene creata anche una sezione su Indico per raccogliere il materiale dei meeting(https://agenda.infn.it/categoryDisplay.py?categId=1036). Stefano segnala che la milestone MS1: Porting e operazione del codice MC in cloud e' stata anticipata al 30/9/2018 rispetto alla data originale del 31/12/2018.

 


Lisa presenta l'architettura ideata per l'esecuzione di job MC su cloud, e i primi test effettuati con i container docker di Geant4 forniti da Enrico e gestiti da Mesos. Viene presentata anche una demo live che lancia 90 job della durata di 5-6 secondi ciascuno (20 atomi tracciati per job) relativi al case study 2, ossia alla simulazione dei processi di effusione e diffusione degli atomi prodotti dalla fissione nel bersaglio. Dalla discussione emerge che i dati di input e output di ogni simulazione saranno sempre file di testo, numerosi ma di pochi kbytes, per cui non sembra necessario avere un filesystem condiviso, che creerebbe un single point of failure. Si ipotizza come soluzione l'uso dell'interfaccia object storage (Swift o S3) del cluster Ceph, che sara' presumibilmente messa in produzione a Marzo 2018. L'architettura presentata non permette di variare dinamicamente in modo automatico il numero di slave Mesos in base al carico di lavoro. Massimo fa notare che un approccio alternativo per l'esecuzione dei job e' attraverso un cluster elastico HTCondor. Questo supporta anche i container docker e appunto avrebbe il vantaggio di allocare-rilasciare risorse in maniera dinamica a seconda delle necessita'. Lisa presenta infine il primo prototipo di interfaccia grafica per lo SPES calculator, che sara' ulteriormente arricchito di funzionalita' nelle prossime settimane.


 


Enrico illustra il significato fisico delle varie fasi di simulazione MC possibili tramite Geant4 e descrive il contentuto dei file di input e output usati nei test di Lisa. Dalla discussione emerge che i container eseguiti nel cluster Mesos di Lisa girano una versione multithread di Geant4 e quindi tendono ad usare tutte le VCPU disponibili in un Mesos slave (4 nei test di Lisa) suddividendo gli atomi per VCPU. Un singolo file di input con N>1 atomi da tracciare viene quindi processato da un job che parallelizza l'esecuzione su piu' VCPU.  I file di output contengono il tempo di rilascio calcolato per ogni atomo tracciato, e andranno quindi in qualche modo aggregati alla fine dell'intera simulazione per ottenere le distribuzioni statistiche del tempo di rilascio per ogni atomo.



Actions:

1) x Enrico: aggiungere al comando docker l'opzione che permetta di definire il nome del file (.tgz) prodotto dalla nostra applicazione Geant4.

2) x Lisa: rendere disponibile da LAN o dall'esterno un indirizzo IP dove poter collegarsi al prototipo del portale ISOLPHARM_Ag per facilitare il feedback degli utenti.