Meeting 10/01/2013

Partecipanti:
@ Bologna
INFN - Sezione Bologna:    Tommaso  Chiarusi, Carmelo  Pellegrino
INFN - CNAF :  Francesco Giacomini, Matteo Manzali
INFN- Sezione di Pisa:  Bachir Boudhaef, Giuseppe Terreni

A)   Revisioni attività in corso
========================

1. Matteo:

1.1 - tre problematiche affrontate:
chiusura thread su socket, su queue, wait for data di Ermes..

	- sulle queue - fixed
	- le altre due situazioni-  w.i.p. :
			-  su socket, utilizzare ASIO con metodi async (toy-server fatto ma da portare sul TriDAS)
			- su Ermes  (sull' HM)

1.2 - pulizia HM, e design
1.3 - setting tag per monior in modo dimanico.
1.4 - alcune cose da rivedere sul wrap days sull' HM
1.5 - implementato interrupt mascherato sul main

1.6 - To Do (pending):  select sui socket con un unico thread

DECISIONE: non ci si cura più del wrap time in quanto per le 8 torri il tempo dati sarà "assoluto"
AZIONE 1 (TOM): chiedere conferma a Fabrizio;
AZIONE 2 (MATTEO): in BOOST-THREAD -> rimozione trattamento wrapping da HM e TCPU (e verificare se anche in EM). Questo perché, anche nel caso della Torre di Nemo Ph2, è la TriDAS_GUI a fermare il run 2 minuti prima del wrap.

DECISIONE: vista la necessità di testare il BOOST-THREAD quanto prima a Portopalo, si decide di "congelare" lo sviluppo del codice non appena  i punti 1.1 saranno sistemati.

2. Budda:
2.1 - overview su global variables:
		- Data Card default
		- puntatori e trasmessi ai thread (ermes, array di socket)

2.2 -parametrizzazioni globali:  GlobalSetup (deriva da IniParser) - preleva info da datacard e/o db.
	- interfaccia da DB compila ma non testata.

	Il TSC centralizzerà l'acquisizione delle DataCard.

Discussione (in corso):
Francesco asserisce che GlobalSetup non dovrà derivare da IniParser ma da una classe completamente virtuale che funga da interfaccia. Da questa dovranno derivare due classi, una per le datacard e l'altra per il DB.

DECISIONE: non si aspetta la definizione della classe di GlobalSetup per il setup da testare a Portopalo.

3. Giuseppe/Bachir:
3.1- portato avanti lo sviluppo del "Plugin Pisa"
3.2- martedi' 14/1 verifica codice congiunto con  Bachir, Giuseppe e Tommaso.

B)  Discussione XDAQ
========================

Si passa in rassegna le impressioni  di tutti avute dopo il meeting su XDAQ tenuto il 18/12/2013.  (LE TRASPARENZE?????)

DECISIONE (roadmap):  
	a.   Francesco e Tommaso si fanno un'idea leggendo la documentazione per stabilire SE XDAQ risulta allettante;
	b.   se il responso è positivo, si deciderà quanto tempo e chi investire per indagare in modo più approfondito (learning-core) la effettiva portabilità del TriDAS su XDAQ.
	c.  a questo punto si tireranno le fila. IMPORTANTE comunque ricordare che il tempo a disposizione per produrre la DAQ per le 8 torri è T_tot=  1 anno effettivo. Di conseguenza, la determinazione del tempo T_lc da impiegare per  il learning-core ( come menzionato al punto b ), deve garantire un tempo T_exit necessario per completare la "exit" strategy (il TriDAS senza XDAQ)
	T_lc = T_tot - T_exit

C) PLANNING
============

1. Schema delle attività'

	1.1- verifica Plugin_Pisa
	1.2- eventuale sua integrazione in boost_thread
	1.3- in parallelo alle precedenti, Matteo continua a lavorare per risolvere le questioni sospese elencate in A.1.1.
	1.4-aspettare ok di Matteo
	1.5- test-bed a Bologna a 64 bit
	1.6- verificare con Jenkins la congruità a 32 bit
	1.7- Portopalo

Deadline  proposta per il  deployment a Portopalo: 4-5 Febbraio.
	
2.  dopo Portopalo riaffronteremo più questioni:
	2.1 : Data format  e metastrutture dati (il PMTHit nell'HM invece che nella TCPU)
	2.2 : TSC come supervisor.

Prossimo Meeting da fissare!