Handle runs in the future

And here is the relevant thread.

Ciao Daniele, grazie mille per la segnalazione.

Dunque: se scarichi il file dalla pagina web http://eee.centrofermi.it/dqmreport/LAQU-01/2014-11-11/LAQU-01_2014-11-10_2014-11-11_summary.root e fai uno scan dei tempi ti accorgi che le ultime entry hanno valori completamente sballati (giustappunto nel 2020).

root [3] Trending.Scan("BinStart")

Row * BinStart *
0 * 248012411 *
1 * 248012472 * ...
1280 * 248093019 *
1285 * 248093313 *
1286 * 432534784 *
1287 * 432534784 *
1288 * 432534784 *
1289 * 432534784 *
1290 * 432534784 *
1291 * 432534784 *
1292 * 432534784 *
1293 * 432534784 *

Il problema pare nei run da http://eee.centrofermi.it/dqm/LAQU-01/2014-11-11/LAQU-01-2014-11-11-00035/ a http://eee.centrofermi.it/dqm/LAQU-01/2014-11-11/LAQU-01-2014-11-11-00048/ In cui ci sono ~50000 eventi (che dal punto di vista delle tracce, i.e. phi, theta, chi quadro, sembrano anche essere sensati) tutti con lo stesso timestamp (nel futuro). Nota che sembra un problema persistente dal run 35 di oggi fino all'ultimo che abbiamo riprocessato. Mi aspetto che senza interventi non si risolva da solo.

Quando faccio il report giornaliero io faccio il merge di tutti i run che sono riuscito a ricostruire senza fare ulteriori verifiche, che e` il motivo per cui i plot che mi hai segnalato sono assurdi.

Dal punto di vista del DAQ hai possibilitadi vedere se il GPS e lockato correttamente? Come ti dicevo le tracce si vedono (quindi mi torna che tu veda l'acquisizione andare) ma i timestamp sono chiaramente assurdi.

Dal punto di vista del DQM io posso mettere un controllo in piuquando processo i run---tipo: sel il timestamp piu piccolo enel futuro non processo gli eventi. Questa e la prima istanza di questo tipo di problema che vedo. Ci penso un secondo.

Grazie ancora per il feedback e fammi pure sapere se posso fare qualcosa per aiutarti a debuggare il problema. Luca

centrofermi / e3pipe

Handle runs in the future #51