# Activities

---

## Setup LNL

### DAQ
* Varie cose funzionano
* Workaround Dyniar (ma solo su Dell)
* frequenza clock configurabile
* 4 canali
* Integrazione doppio transceiver della KCU. Al momento ne usiamo solo 1 ==> 4 canali, con il secondo arriviamo ad 8
* Da tener sotto controllo l'occupanza delle LUT (attualmente al 57%)
* Da capire come alloggiare 2 KCU nello stesso server
* spazio fisico
* 1 o 2 DMA?
* Con 2 DMA avremmo 2 stream, 2 file scritti, 2 Kafka producer, etc.
* Riusciremmo però a leggere tutte le OBDT del settore (14?) con un solo server
* Domini di clock diversi per disaccopiare lettura e scrittura

### Test OBDTv2
* Quando?
* lpGBT su KCU sembra funzionare
* test di trasmissione dati da OBDT a KCU successful
* Va integrato quel blocco con il resto del fw della KCU
* Fare il punto sulle fibre che servono.

### Camerette
* Curare canali morti/inefficienti
* Pazzini in rifacimento (ri-tirati i fili mancanti, HVB e HVC da finire di installare), da testare HV
* Vari altri sulle altre camere.
* Abbiamo inventario?
* Allineamento non ancora ok, è "dritta" quella in basso, mancano le altre, faremo.
* Plot per paper. Serve altro run lungo in condizioni ottimali?
* Schedine per controllo e LV forse pronte per la prossima visita di luigi
* Cavi nuovi: Luciano per farne a sufficienza per 8 camere, sia in verisone yamaichi-yamaichi che yamaichi-nuovo connettore. Lunghezza da definire
* Split da recuperare per entrare sia su V7 che OBDT: ce ne sono 2 a PD rotto (?), altre al CERN (5 nell'armadio a SX5, altre?) da recuperare alla prox missione

### Trigger esterno
* Al momento PM unica soluzione funzionante, ma rate molto bassa (2Hz). Disposizione ortogonale ai fili (intercettano più macrocelle)
* SiPM di Simi/Dal Corso non fanno: instabilità notevole in funzione del tempo e senza apperenti variazioni delle condizioni al contorno (coincidenza quadrupla oscilla tra 20 e 60 Hz)
* Sono disponibili altre palette di scintillatore con la scavo e la fibra già stesa. Ci dovrebbero anche essere dei SiPM buoni (da capire se quelli di Longhin -che ne ha migliaia- siano troppo grandi, probabilmente si). Possiamo cioè produrre altri scintillatori.
* Gabriele ha condiviso gli schemi per [alimentazione/connettori](https://drive.google.com/drive/folders/1P06n2WdeCDCtM-H4gSrWG-Zv7f6e4vXo?usp=sharing) e per [amplificatore](https://drive.google.com/drive/folders/1cREjVNmOLj_Mm2aMnYdyEYcgkh_R0WiV?usp=sharing)
* Dobbiamo capire a chi farlo fare: Luciano (chiedere a Marco B.)? Qualcuno di Marino?

### DQM
* Review del lavoro dello studente sul DQM basato sul NPLM: incontriamolo e facciamoci mostrare cosa ottiene (le ha già mostrate e Wulzer et al, entusiasti)
* Capire come farne il deployment
* processo di stima del p value prende tempo su CPU (corrisponde all'allenamento della rete)
* stanno discutendo di portare l'algoritmo in Falkon (versione dell'algoritmo dei genovesi basata su kernel gaussiani invece che su un NN).
* Estensione a più dimensioni. Quali? Variabili di traccia del trigger? (serve che siano correlati, anche se non strettamente necessario)
### Varie

* link a 40Gbs in uscita (serve se mettiamo su processing locale?)
* Presentazione al gruppo del calcolo di LNL (Gulimini et al.)
---

## Trigger
* Stato dell'arte? Sarebbe bene preparare una presentazione ad uso interno per fare il punto su quello che vediamo con 5 macrocelle per camera
* Ri-training con su dataset più accurato?
* Piani per sviluppo orizzontale e verticale
---

## RDMA
* Stato delle cose?

## Attività al CERN

### DT Scouting
* Canale 2 funziona, leggiamo correttamente
* Stato del mapping?
- [ ] Matteo implementa un registro su PCIe per caricare mapping "dinamicamente"
* Sarebbe interessante avere un mini-dimostratore della catena da mostrare a CMS
- [ ] capire il mapping e integrare nel processing (mapping on-the-fly durante DMA o a posteriori)
- [ ] possibile tirare su un nuovo cluster con webUI dedicata a LHC runs?
- [ ] nel caso, un paio di plot di base per mostrare che siamo in grado di leggere e fare un minimo di processing (anche solo per DQM)

### Integrazione e test OBDTv2
* OBDTv2 collegate a MB4 (qual è?), ragionevole pianificarlo per inizio 2022?
* Che sistema utilizzare per readout? Scheda di Costas? Integrazione con catena di trigger
* Parliamone alla CMS week

### DAQ Scouting
* News da Rocco su deployment VCU o altro e/o da Gaia
* Porting del firmware della kcu1500 su vcu128 in stato avanzato
* Risolti problemi di stabilità dei link che impedivano il corretto allineamento tra i link e ne causavano il reset periodico (problema presente e risolto anche su kcu e micron boards)
* Migliorata stabilità della logica tra transceivers e DMA
* DMA funzionante e stabile usando wz-dma driver (xdma driver funziona in modo leggermente diverso e causa problemi)
* Set-up validato con test pattern inviati da una mp7
* Girato anche il software di unpacking sui dati acquisiti da DMA e prodotti dei plot: non si vedono anomalie macroscopiche
* Si pensa al deployment in P5 per Gennaio-Febbraio, usando per ora DMA e non TCP/IP (tutto da vedere)
* Dovremmo cominciare a guardare i dati che raccolgono..

### Infrastruttura
* Risorse k8. Non si capisce una mazza. CMS non ci dà controllo, IT?
* Deploy e test dello stesso container di lnl/pd: kafka producer su server lab b40 del DAQ (collegato a MP7 che emula GMT), cluster k8 dell IT
* Definizione manifesto per configurazione come cluster k8 delle nuove BU in .cms
* Test di quest'ultimo (contro DT o DAQ scouting)
* Dobbiamo studiare assieme uno schema di processing per il DAQ scouting. Nello schema attuale sarebbe a valle dello switch che riceve i dati per orbita dalle varie sorgenti
* Presentazione all'IT (Luca Canali)

### Varie
* proponiamo di portare cameretta al 904? Magari parliamone anche con Grabriella. Serve cmq avere il necessario per replicare i servizi.
* Sentire Fasanella

---

## LEMMA
* Breve sommario della [situazione](https://agenda.infn.it/event/28673/contributions/145880/attachments/85978/114293/LEMMA-TB_Padova.pptx):
* Il futuro del muon collider è incerto, ancora di più quello di LEMMA. L'esperimento però continua ad essere supportato. E a noi ci piace.
* Wisconsin è del gruppo: si occupano di sim/reco e di GEM e loro elettronica
* Interessanti visite al CERN: GEM (su H4, stessa scheda PCIe per il DAQ) e pixel in camera pulita.
* Abbiamo i pixel ma nudi. Ci prestano un modulo DTB per testarli. L'idea è di portare tutto a casa dal CERN alla prossima missione.
* CHROMIE non ha ancora preso dati, stanno discutendo il recupero delle componenti che servono per replicare il sistema di acquisizione, controllo, etc. A noi dovrebbe toccare una motherboard (to be seen).
* Torino (Amapane) dovrebbe occuparsi del trigger, Bari della produzione e operazione dell GEM, noi delle camerette e dei pixel, Roma dei calorimetri. Reco e simulazione in mano a Bertolin/Sestini e Rosati (Roma1). I primi spariscono (bene), il secondo è lanciato
* La meccanica per i pixel ce la dovrebbe prestare CHROMIE, ma non sarebbe male rifarsela qui
* Organizzare riunione su simulazione estesa a tutta la "collaborazione"
* Riunione con Wisconsin e Baresi su readout delle GEM
* Pigliare un OBDT, sgarattarla e farla diventare la scheda per i pixel!

---

## Articoli
* Infrastruttura acquisizione e processing online: sottomesso a NIM e mandato all'[archivio](https://arxiv.org/abs/2111.05155)
* [MiniDT](https://www.overleaf.com/project/603e79eb35d959134a339f3e)
* scrivere parte di meccanica
* plot di performance definitivi?
* Trigger. Che ne facciamo della [versione attuale](https://www.overleaf.com/project/606f0bbc074f294955022f1b) nell'(archivio)[https://arxiv.org/abs/2105.04428]?
* DQM. Ci sta un articolo una volta finalizzato e messo in opera l'algoritmo dello studenti

---

## Acquisti
* Server per processing a LNL ed ospitare A100 e Alveo.
* Troppi pochi soldi per un acquisto decente da usare per la A100 --> Rimandato all'anno prossimo
* Fibre del sesso giusto
* da acquistare dal laboratorio di Bellato

## Overall planning DT/40MHz @ CERN
* Cameretta al 904
* la portiamo su cmq per la CMS week?
* 40 MHz da settore con OBDTv1 (non urgentissimo)
* Serve mapping interno, eventualmente da deployare nel fw della KCU
* Con se il mapping è corretto, si può girare sulla KCU il nostro algoritmo di "trigger"
* Serve il mapping esterno, ovvero quali fibre (<==> OBDT) stiamo leggendo come sono collegati gli yamaichi di ciascuna OBDT alle camere (mapping implementato nel DQM?)
* Studi di correlazione tra i nostri dati e quelli del mini/c-DAQ. Non possiamo iniettare il L1A nel nostro sistema (veramente?), ma abbiamo orbita e BX, dovrebbe esser semplice ritrovare i loro trigger nei nostri dati.
* Come possiamo leggere le altre OBDT? Estensione a 4 (8) canali per server ed eventualmente a due server
* OBDTv2 per leggere MB4 e da leggere via scheda di Kostas