Warszawa 5 października 2009

Prezentacja na temat: "Warszawa 5 października 2009"— Zapis prezentacji:

1 Warszawa 5 października 2009
Optimization, Synchronization, Calibration and Diagnostic of the RPC PAC Muon Trigger System for the CMS detector. Praca moja dotyczyła trygera czyli systemu wyzwalania dla eksperymentu CMS, a konkretnie cześci systemu trygera opartego na detektorach RPC. Skrót PAC, czyli Pattern Comparator oznacza algorytm identyfikacji mionow zastosowany w tym systemie. Warszawa 5 października 2009

2 Zagadnienia omawiane w pracy
Cel: Zapewnić jak najlepsze działanie systemu trygera mionowego RPC PAC, co bezpośrednio przekłada się na jakość wyników fizycznych eksperymentu CMS System kontroli, monitorowania i diagnostyki trygera mionowego RPC PAC Architektura oprogramowania kontrolującego tryger RPC PAC. Proces konfiguracji systemu trygera RPC PAC. Procedury testowe dla elektroniki trygera. Procedury monitorujące system trygera (stan elektroniki, jakość danych z detektora, jakość działania trygera). Synchronizacja trygera mionowego RPC PAC Analiza czasu lotu mionów w detektorze CMS i czasu propagacji sygnałów z detektora do elektroniki odczytowej. Metoda obliczania parametrów synchronizujących dane z detektora; metoda obliczania poprawek do tych parametrów na podstawie analizy sygnałów od mionów pochodzących ze zderzeń w LHC. Synchronizacja tryger PAC RPC dla mionów kosmicznych jako weryfikacja przedstawionej metody. Podstawowym celem działalności opisanych w mojej pracy było zapewnienie jak najlepszego działanie systemu trygera mionowego RPC PAC, co bezpośrednio przekłada się na jakość wyników fizycznych eksperymentu CMS. Praca obejmuje dwa podstawowe zagadnienia. Pierwsze z nich to system kontroli, monitorowania i diagnostyki trygera mionowego RPC PAC. Drugim zagadnieniem jest synchronizacja trygera. W pracy omawiam architekturę systemu kontroli i diagnostyki oraz jego podstawowe funkcjonalności, czyli: konfiguracja systemu trygera RPC PAC, procedury testowe oraz procedury diagnostyczne i monitorujące. W pracy najpierw analizuje właściwości czasowe sygnłów od mionów w detektorze CMS, a następnie przedstawiam metody znajdowania parametrów zapewniających właściwą synchronizację danych wykorzystywanych w procesie trygerowania w systemie RPC PAC. Warszawa , 5 października 2009 Karol Buńkowski, UW

3 Wielki Zderzacz Hadronowy LHC
Kołowy akcelerator cząstek, największy jaki dotychczas zbudowano. Przyśpiesza i zderza protony oraz ciężkie jony. Znajduję się on w laboratorium CERN pod Genewą. Eksperyment CMS, którego dotycz moja praca, jest jednym z czterech detektorów zbudowanych dla akceleratora LHC. Będą w nim przyśpieszane i zderzane protony oraz ciężkie jony. Jego powtórne uruchomienie, po zeszłorocznej awarii planowane jest na listopad tego roku. Detektor CMS jest jednym z 4 detektorów pracujących przy akceleratorze LHC. ATLAS i CMS to detektory ogólnego przeznaczenia, LHC-B dedydkownany dla kwarków B, ALICE dla ciężkich jonów LHC przyśpiesza i zderza ze sobą protony, planowane są także runy z ciężkimi jonami LHC został uruchomiony po raz pierwszy we wrześniu zeszłego roku, wiązkę protonów przecyrkulowno w obu kierunkach, potem nastąpiła słynna awaria. Następne uruchomienie planowane na listopad tego roku Warszawa , 5 października 2009 Karol Buńkowski, UW

4 CMS - Compact Muon Solenoid
: Drift Tube Cathode Strip Chambers Resistive Plate Chambers hadronic calorimeter Detektor CMS zbudowany według schematu typowego dla detektorów pracujących na zderzeczach: kolejne warstwy detektorów różnych typów cylindrycznie otaczają punkt zderzeń. I tak, wewnątrz nadprzewodzącej cewki magnetycznej znajduje się detektor śladowy (czyli tracker) oraz kalorymetry elektoromagnetyczny i hadronowy. Na zewnątrz cewki umieszczono kilka warstw detektorów mionów: w centralnej części, czyli w beczce znajdują się komory dryfowe, czyli Drift Tube, w pokrywach proporcjonalne komory typu Cathode Strip Chambers, dodatkowo, zarówno w beczce jak i w pokrywach znajdują się komory Resistive Plate Chambers. - CMS – Compact Muon Solenoid Detektor zbudowany według schematu typowego dla detektorów pracujących na zderzeczach: kolejne warstwy detektorów różnych typów cylindrycznie otaczają punkt zderzeń i tak: najbliżej punktu oddziaływań znajduje się detektor śladowy (czyli tracker), w wypadku CMS całkowicie krzemowy dalej kalorymetry elektoromagnetynczy i hadronowy zewnętrzną warstwę stanowią detektory mionów: w centralnej części, czyli w beczce komory DT (beczka podzielona jest na 5 kół), w pokrywach CSC, oraz dodatkowo komory RPC jednym z najważniejszych elementów jest nadprzewodząca cewka produkujące pole magnetyczne umożliwiające pomiar pędu poprzecznego cząstek naładowanych – pole zakrzywia tory cząstek, zakrzywienie tym mniejsze im większy pęd poprzeczny (czyli składowa pędu prostopadła do osi wiązki) - CMS, co jest podkreślone w nazwie, został zoptymalizowany do pomiaru mionów. Pole magnetyczne na zewnątrz cewki jest zamykane przez żelazne jarzmo, dzięki czemu także na zewnątrz jest silne (do 2T). Cztery warstwy komór minowych. Miony są szczególnie cenne dla badania fizyki w LHC, gdyż dają czysty sygnał: poza kalorymetry nie wylatuje praktycznie nic poza mionami CMS w dużej części gotowy, testowany i kalibrowany przy pomocy mionów kosmicznych (zebrano 380 mln przypadków przy włączonym magnesie), widział wiązkę LHC we wrześniu 2008 The TOTEM Experiment will measure the total pp cross-section with the luminosity-independent method and study elastic and diffractive scattering at the LHC. Całkowita waga: t Średnica: 15 m Długość: 21.6 m Pole magnetyczne: 4 Tesla Pokrycie w : 5.5 kalorymetr forward 2.1 system mionowy Warszawa , 5 października 2009 Karol Buńkowski, UW

5 CMS - Compact Muon Solenoid
Detektor CMS jest w zasadzie gotowy. Od 2 lat zbiera dane, na razie miony kosmiczne, jako że LHC jeszcze nie działa. Tylko w tym roku zebrano ok. 500 mionów przypadków z mionami. Dane te służą da testowania i kalibracji detektora. CMS od 2 lat zbiera dane – miony kosmiczne! ~500 milionów mionów w tym roku Warszawa , 5 października 2009 Karol Buńkowski, UW

6 Dlaczego wyzwalanie (tryger) w LHC?
2  2875 paczek protonów, odległość między paczkami 7.5 m = 25 ns 1011 protonów / paczka E = 7 TeV na proton 40 milionów przecięć paczek / s ~ 20 oddziaływań proton-proton co każde 25 ns, W wyniku których powstają setki cząstek Odpowiedz detektora ~1 MByte danych (skompresowanych)  4  1013 Bytes ( GB) / s Strumień danych niemożliwy do zapisania Jednym z kluczowych elementów eksperymentów przy LHC jest tak zwany system wyzwalania, czyli z angielskiego tryger. Interesujące procesy fizyczne, które mamy nadzieję zbadać w LHC są niezwykle rzadkie. Dlatego potrzeba bardzo dużej częstości zderzeń, aby je zaobserwować. W LHC protony nie będą równomiernie rozłożone po obwodzie akceleratora, ale będą pogrupowane w paczki. Przecięcia paczek zachodzić będą co 25 ns, czyli 40 milinów razy na sekundę. Zadaniem detektorów jest rejestracja produktów zderzeń proto-proton. W przypadku detektora CMS każde przecięcie paczek to ok. 1 MB danych. Kiedy przemnożymy ten jeden MB przez 40 milonów przecieć na sekundę, otrzymamy strumień danych który niemożliwy do zapisania na trwałych nośnikach (chyba ze dysponujemy nieskończonymi funduszami). Dlaczego system wyzwalania jest tak ważny? Otóż w LHC protony nie będą równomiernie rozłożone po obwodzie akceleratora, ale będą pogrupowane w paczki. Odległość między kolejnymi paczkami to ok. 7.5 m. Przy prędkości bliskiej prędkości światła, z jaką poruszają się protony, 7.5 m równa się 25 ns. Tak wiec przecięcia paczek protonów będą zachodzić co 25 ns, czyli 40 mln razy na sekundę. W każdym przecięciu paczek dojdzie do ok. 20 twardych oddziaływań proton-proton, a w wyniku których powstaną setki wtórnych cząstek. Zadaniem detektorów jest rejestracja tych cząstek powstałych w zderzeniach. W przypadku detektora CMS te kilkaset cząstek wyprodukuje ok. 1 MB danych. Kiedy przemnożymy ten jeden MB z jednego przecięcia przez 40 milonów przecieć na sekundę, otrzymamy strumień danych o wielkości 40 tysięcy GB na sekundę. Jest to strumień danych przy obecnej technice niemożliwy do zapisania na trwałych nośnikach (chyba ze dysponujemy nieskończonymi funduszami). Protony pogrupowane w paczki, odległość miedzy paczkami 7,5 m  częstość zderzeń 25 ns czyli 40 MHz Warszawa , 5 października 2009 Karol Buńkowski, UW

7 Dlaczego wyzwalanie (tryger) w LHC? (2)
Zderzenia p-p Większość ze zdarzeń -„klasyczna”, dobrze znana fizyka Sygnatura: niskie pędy poprzeczne (pT) Interesują nas bardzo rzadkie zdarzenia w których powstały nowe ciężkie cząstki Rozpadają się one na wysokoenergetyczne obiekty: dżety hadronowe, leptony, fotony Ten wykres przedstawia na lewej osi pionowej częstość zdarzeń. Nowa, interesująca fizyka, to kolorowe linie na dole rysunku. Widać, że np. bozon higgsa bądź cząstki supersymetryczne będą się pojawiać rzadziej niż raz na sekundę. Oznacza to, że nie ma sensu zapisywać wszystkich 40 mln zdarzeń na sekundę, ale tylko te które są, przynajmniej potencjalnie, interesujące. Te nowe, interesujących obiekty są ciężkie. Na poziomej osi jest ich spodziewana masa. Dlatego produkty ich rozpadu będą miały wysoką energię i pęd poprzeczny. Tak więc jeśli w przypadku pojawią się takie wysokoenergetyczne obiekty, jest to sygnatura, że przypadek warto zapisać. Pęd poprzeczny: składowa pędu prostopadła do osi wiązki Sygnatura: wysokie pędy poprzeczne (pT) symulacje Warszawa , 5 października 2009 Karol Buńkowski, UW

8 System wyzwalania („tryger”)
Pierwszy etap fizycznych analiz danych zebranych przez detektor zapisz odrzuć Ocenia wybrane, zgrubne dane z każdego przecięcia paczek i na ich podstawie decyduje czy: Zapisać zdarzenie do pamięci masowej (z rzadka) Czy też je odrzucić (niemal zawsze) I właśnie do podejmowania decyzji o zapisaniu bądź odrzuceniu przypadku służy system wyzwalania, czyli tryger. System ten dokonuję pierwszego etapu fizycznych analiz danych. Odczytuje on dla każdego przecięcia wybrane dane z detektora, i poszukuje w nich tych wysokoenergetycznych obiektów. Najważniejszym wymaganiem jest to aby nie zgubić interesujących przypadków, ale równocześnie częstość zaakceptowanych przypadków nie może przekraczać maksymalnej przepustowości systemu akwizycji danych. Ale za cenę wysokiej efektywności trzeba się pogodzić z tym, że zaakceptowanych zostanie też wiele przypadków, w których nic ciekawego się nie pojawiło, gdyż system wyzwalania, aby być szybkim, nie może być zbyt dokładnym. Dlatego drugim podstawowym wymaganiem jest aby częstość zaakceptowanych przypadków nie przekraczała maksymalnej przepustowości systemu akwizycji danych. Najważniejsze to nie zgubić interesujących przypadków = wysoka efektywność Oraz zapewnić, aby wyjściowa częstość zaakceptowanych przypadków nie przekraczała maksymalnej przepustowości systemu akwizycji danych Warszawa , 5 października 2009 Karol Buńkowski, UW

9 System wyzwalania i akwizycji danych w CMS
Detektor Tryger pierwszego stopnia (Level 1) Dedykowana 40 MHz, tylko funkcje logiczne Analizuje każde przecięcie paczek  przetwarzanie potokowe; wypracowanie decyzji s, w tym ~2 s transmisja danych Wyjście ≤ 100 kHz zgrubne dane Bufory odczytowe na 128 przypadków = 3.2 s zachowaj odrzuć DAQ: wybrane przypadki, pofragmentowane Event Builder Gromadzi dane dla jednego przypadku w jednym komputerze HLT W eksperymencie CMS system wyzwalana jest podzielony na dwie główne części. Tryger pierwszego stopnia zrealizowany jest całkowicie w dedykowanej elektronice. Jego zadaniem jest ocena danych z każdego przecięcia paczek, a dane te, jak mówiłem napływają z częstością 40 MHz. Dlatego system ten w analizie danych wykorzystuje jedynie funkcje logiczne i przetwarzanie potokowe. W przypadku pozytywnej decyzji trygera pierwszego stopnia pełne dane z przypadku są odczytywane z buforów przez system akwizycji danych, następnie, poprzez tak zwany Event Builder, przesyłane są do trygera wyższego stopnia. Tryger wyższego stopnia jest realizowany przez dedykowane oprogramowanie pracujące na farmie ok komputerów. Czas na podjęcie decyzji o odrzuceniu bądź zaakceptowaniu przypadku to 3.2 s, z tym że ~2 s zajmuję transmisja danych pomiędzy elementami systemu. Maksymalna dopuszczalna częstość zaakceptowanych przypadków to 100 kHz. Dane z jednego przypadku rozrzucone są po wielu buforach odczytowych, dlatego przed przekazaniem do trygera wyższego stopnia muszą zostać zgromadzone w jednym miejscu komputerze. Służy do tego event builder, który jest siecią opartą na technologii stosowanej w klastrach komputerowych. HLT - przypadek jest stopniowo rekonstruowany, i jednocześnie aplikowane są cięcia i podejmowana jest decyzja o odrzuceniu przypadku. Finlnie, jedynie 100 przypadków na sekundę zapisywaych jest na taśmach magnetycznych. Tryger wyższego stopnia (HLT) Farma ~1000 komputerów, wykonujących algorytmy selekcji przypadków – analiza danych w czasie rzeczywistym: Stopniowa rekonstrukcja przypadku Uwzględniona kinematyka i topologia przypadku Informacje z trackera, pełny tracking Redukcja przypadków ze 100 kHz do 100 Hz zapisywanych na taśmach magnetycznych Warszawa , 5 października 2009 Karol Buńkowski, UW

10 Tryger pierwszego stopnia (Level 1)
Calorimeter Trigger Muon Trigger DAQ ECAL Trigger Primitives RPC hits CSC hits DT hits HCAL Trigger Primitives Podsystemy trygera: Identyfikuj, mierzą i sortują obiekty trygerowe Link system Segment finder Segment finder Regional Calorimeter Trigger Pattern Comparator Track finder Track finder 40 MHz pipeline 4+4 m 4 m 4 m MIP+ ISO bits Global Calorimeter Trigger Global Muon Trigger Algorytmy GT: cięcia uwzględniają lokalizacje i koincydencje obiektów System trygera pierwszego stopnia składa się z dwóch podsystemów: tryger kalorymetryczny który analizujący dane z kalorymetrów, oraz trygera oparty na detektorach mionowych. System trygera RPC PAC, którego dotyczy moja praca, jest właśnie jednym z trzech podsystemów trygera mionowego. Zadaniem podsystemów jest identyfikacja oraz pomiar obiektów, takich jak wysokoenergetyczne fotony, elektrony, dżety hadronowe oraz miony, które to obiekty mogą być sygnaturą pojawienia się w przypadku cząstek nowej fizyki. Znalezione obiekty trygerowe są przesyłane do układu Globalnego Trygera, który analizując te obiekty podejmuje decyzje o odczytaniu bądź odrzuceniu przypadku. Calorimeter Trigger: candidates for isolated and non-isolated electrons/photons, hadron jets and calculates energy sums Tracker nie jest wykorzystywany w L1 GT – algortymt nie jest zwykłym ORem sygnałow z podsystemów Cały system pracuje synchronicznie z 40 MHz zegarem z jednego źródła (czyli z LHC) L1A – Level One Accept – trigger signal e/, J, ET, HT, ETmiss miony Global Trigger Obiekty trygerowe -Sygnatury nowej fizyki L1A (trigger) Status TTC system TTS system 32 partitions Detectors Frontend Warszawa , 5 października 2009 Karol Buńkowski, UW

11 Tryger mionowy Trzy niezależne, redundantne podsystemy:
Wymagania (ustalone przez symulacje kanałów nowej fizyki): Identyfikacja mionów, zakładana efektywność >95% dla mionów o pT > 40 GeV Odpowiednio dokładny pomiar pędu i znaku mionów (po cięciu na ok. 25 GeV/c częstość trygera < 12.5 kHz) Niski poziom fałszywych trygerów i „duchów” Jednoznaczne przypisanie mionu do zdarzenia (przecięcia paczek) Trzy niezależne, redundantne podsystemy: Drift Tube – beczka Cathode Strip Chambers – pokrywy Resistive Plate Chambers – beczka i pokrywy Global Muon Trigger – dopasowanie i scalanie mionów z trzech podsystemów Tryger mionowy składa się z trzech niezależnych, redundantnych podsystemów opartych na trzech typach detektorów mionowych: DT, CSC i RPC. System Globalnego Trygera Mionowega dopasowuje do siebie miony znalezione przez te podsystemy i przesyła je do Globalnego Trygera. To, ze tryger mionowy jest redundantny zapewnia lepszą efektywność i czystość trygera mionowego. Widać to na tym wykresie. Przedstawia on częstość przypadków z mionami, przypadków znalezionych przez poszczególne podsystemy mionowe, w zależności od ciecia na pęd mionu, ale pęd zmierzony przez dany podsystem. Kółka to DT i CSC razem, krzyżyki to RPC. Widać że częstości te są o około rząd wielkości większe niż częstość mionów dla ich faktycznego pędu (linia ciągła). Wynika to stąd, że podsystemy mionowe przeszacowują pęd mionu aby uzyskać dużą efektywność. Ale kiedy globalny tryger mionowy zgra ze sobą pomiary z trzech podsystemów, częstość na wybranym progu obniża się blisko 5 razy. Nie do przecenienia jest też większa niezawodność takiego zdublowanego systemu trygera. Dodatkowo, osiąga się pewniejsze przypisanie mionu do przecięcia. Jest bardzo ważne aby znaleziony mion był jednoznacznie przypisany do przecięcia (czyli zdarzenia) z którego pochodzi. Tylko wtedy system akwizycji odczytane właściwe dane, a nie dane z jakiegoś następnego bądź poprzedniego przypadku. Szczególnie użyteczny jest tutaj systemu RPC, gdyż komory RPC mają bardzo dobrą rozdzielczość czasową. Jednym z podstawowych wymagań dla trygera mionowego jest bardzo wysoka efektywność identyfikacji wysokoenergetycznych mionów – powyżej 95%. Dodatkowo, tyger mionowy musi odpowiednio dokładnie wyznaczać pęd i znak znalezionych mionów. Bardzo ważnym wymaganiem jest to, aby znaleziony mion był jednoznacznie przypisany do przecięcia (czyli zdarzenia) z którego pochodzi. Tylko wtedy z buforów danych zostaną odczytane właściwe dane, a nie dane z jakiegoś następnego bądź poprzedniego przypadku. jednakże aby osiągnąć tak dużą efektywność dla wysokoenergetycznych mionów, trzeba pogodzić się z tym, że sporo niskoenergetycznych mionów będzie rozpoznawana jako wysokoenergetyczne, gdyż w trygerzez L1 trudno o dokładny pomiar pędu jednak z drugiej strony, pomiar pędu musi być na tyle dokładny, aby nie trzeba było stosować zbyt wysokiego cięcia na pT, potrzebnego do uzyskania zakładanej częstości wyjściowej Jest to ważne dla tego, że o ile większość poddetektorów, gdy dostaje pozytywną decyzję o odczycie danych z danego przecięcia, to może zapisać także dane z kilku sąsiednich przecięć, to tracker tego nie potrafi. Lepsza efektywność trygera Lepsza czystość (selektywność) Większa niezawodność Pewniejsza synchronizacja mionów z przecięciem Warszawa , 5 października 2009 Karol Buńkowski, UW

12 System trygera mionowego RPC PAC
Komory RPC: Od 4 do 6 warstw komór otaczających punkt zderzeń 984 komór, ~ pasków odczytowych System linkowy synchronizacja i kompresja danych z komór 1232 Link Board-ów w 96 kasetach, ~3000 dużych, programowalnych układów FPGA 1104 połączeń światłowodowych System trygerowy poszukiwanie mionów: algorytm PAttern Comparator (PAC) - koincydencja czasowa i przestrzenna sygnałów z kilku komór: 84 Trigger Board-ów w 12 kasetach, ~1000 dużych, programowalnych układów FPGA Komory Resistive Plate Chambers na jednym z dysków pokrywy Podstawą trygera PAC są detektory Resistive Plate Chambers wykrywające przelot mionów. W CMSie znajduje się blisko 1000 komór RPC posiadających w sumie ok pasków odczytowych Warszawa , 5 października 2009 Karol Buńkowski, UW

13 System trygera mionowego RPC PAC
Komory RPC: Od 4 do 6 warstw komór otaczających punkt zderzeń 984 komór, ~ pasków odczytowych System linkowy synchronizacja i kompresja danych z komór 1232 Link Board-ów w 96 kasetach, ~3000 dużych, programowalnych układów FPGA 1104 połączeń światłowodowych System trygerowy poszukiwanie mionów: algorytm PAttern Comparator (PAC) - koincydencja czasowa i przestrzenna sygnałów z kilku komór: 84 Trigger Board-ów w 12 kasetach, ~1000 dużych, programowalnych układów FPGA W samym sytemie trygra wyróżniamy dwie części. Tak zwany system linkowy, a konkretnie płyty Link Board, odczytują sygnały z komór, synchronizują je, kompresują i wysyłają światłowodami do elektroniki poszukującej mionów. Mamy w sumie ok płyt Link Board i ponad 1000 połączeń światłowodowych. Płyty Link Board z podłączonymi światłowodami Warszawa , 5 października 2009 Karol Buńkowski, UW

14 System trygera mionowego RPC PAC
Komory RPC: Od 4 do 6 warstw komór otaczających punkt zderzeń 984 komór, ~ pasków odczytowych System linkowy synchronizacja i kompresja danych z komór 1232 Link Board-ów w 96 kasetach, ~3000 dużych, programowalnych układów FPGA 1104 połączeń światłowodowych System trygerowy poszukiwanie mionów: algorytm PAttern Comparator (PAC) - koincydencja czasowa i przestrzenna sygnałów z kilku komór: 84 Trigger Board-ów w 12 kasetach, ~1000 dużych, programowalnych układów FPGA Część trygerowa poszukuje mionów przy pomocy algorytmu Pattern Comparator (stąd nazwa PAC). W algorytmie tym wymagana jest czasowa i przestrzenna koincydencja sygnałów z kilku komór leżących na drodze mionu lecącego z punkty zderzeń. Algorytm ten jest wykonywane przez 84 płyty Trygger Board, na każdej z nich znajdują się cztery układy PAC. We wszystkich płytach w systemie procesowanie danych i algorytmy trygerowe są zaimplementowane w dużych, programowalnych układach elektronicznych w technologii FPGA, Warszawa , 5 października 2009 Karol Buńkowski, UW

15 System trygera mionowego RPC PAC
System zaprojektowany i zbudowany przez Warszawską Grupę CMS (UW, IPJ, PW), Komory RPC: Od 4 do 6 warstw komór otaczających punkt zderzeń 984 komór, ~ pasków odczytowych System linkowy synchronizacja i kompresja danych z komór 1232 Link Board-ów w 96 kasetach, ~3000 dużych, programowalnych układów FPGA 1104 połączeń światłowodowych System trygerowy poszukiwanie mionów: algorytm PAttern Comparator (PAC) - koincydencja czasowa i przestrzenna sygnałów z kilku komór: 84 Trigger Board-ów w 12 kasetach, ~1000 dużych, programowalnych układów FPGA ~1500 płyt, 12 typów ~4000 układów FPGA, 15 typów Duża skala i złożoność systemu  nie dałoby się zbudować, uruchomić i użytkować takiego systemu bez zaawansowanych narzędzi do kontroli i diagnostyki Moja rola: projekt systemu kontroli i monitorowania Metody analizy danych diagnostycznych Rozwijanie oprogramowania kontrolującego i monitorującego system trygera RPC PAC W sumie system trygera PAC składa się z ok płyt elektronicznych, 12 różnych typów. Płyty te zawierają w sumie ok dużych programowalnych układów FPGA, 15 różnych typów – dla każdego z tych typów potrzebny jest inny, dedykowany firmware. Jest jasne, że przy tak dużej złożoności systemu nie dałoby się go zbudować, uruchomić i użytkować bez zaawansowanych i rozbudowanych narzędzi do kontroli i diagnostyki. Moduły diagnostyczne implementowane bezpośrednio w elektronice oraz oprogramowanie kontrolne były rozwijane już na etapie tworzenia i testowania prototypów elektroniki. Ja właśnie wtedy dołączyłem do warszawskiej grupy CMS, zajmowałem się między innymi testowaniem tychże prototypów, brałem udział w testach z synchroniczana wiązką mionów. Doświadczenia zebrane podczas tej fazy pozwoliły nam poznać przydatność różnych narzędzi diagnostycznych i nauczyć się ich najlepszego wykorzystania. Doświadczenia te zostały wykorzystane podczas tworzenia finalnego systemu. Moja rola polegała tutaj na udziale w projektowaniu sytemu kontroli i diagnostyki, opracowaniu metod analizy danych diagnostycznych, oraz rozwijaniu oprogramowania. Boards: FEB, DB, CB, LB, FEC, CSC, SP, TB, TCB, HSB, FSB, DCC, SP SynCoder, LBC, CBIC, CBPC, VME, CONTR, OPTO, PAC, RMB, TBGBS, TCGBS, HS, FS, DCC*2 Warszawa , 5 października 2009 Karol Buńkowski, UW

16 System kontroli i monitorowania
DB On-line Software Trigger algorithm Data compression Diagnostic DAQ Transmission Link Boards Trigger Crates System elektroniczny jest kontrolowany przez dedykowane oprogramowanie - rozproszony, wielowątkowy system komputerowy: Konfiguracja systemu; parametry przechowywane w bazie danych, możliwych wiele wersje konfiguracji Diagnostyka i monitorowanie: Wykrywanie i lokalizacja usterek i uszkodzeń, Sprawdzanie poprawności konfiguracji Narzędzia do testowanie i wyszukiwania błędów w systemie elektronicznym: Testy implementacji algorytmów (porównywanie z emulatorem) Testy poprawności podłączeń kabli Testowanie prototypów, Detector Control Control CCU VME Control channels W układach FPGA zaimplementowano obok algorytmów trygera rozbudowaną warstwę diagnostyczną: moduły odczytu diagnostycznego – podglądanie danych płynących przez system wielokanałowe liczniki i moduły histogramujące pozwalające mierzyć częstość sygnałów z komór i częstość mionów moduły weryfikujące poprawność transmisji + liczniki błędów generatory danych testowych Ostatecznie stworzyliśmy rozproszony, wielowątkowy system komputerowy umożliwiający pełną i łatwą kontrolę systemu trygera. Jego podstawowe funkcjonalności to: przygotowanie systemu trygera do działania czyli jego konfiguracja, diagnostyka i monitorowanie trygera podczas zbierania danych, Stworzony został również zestaw narzędzi do testowanie i wyszukiwania błędów i usterek w systemie elektronicznym. Równie ważne jak software są moduły diagnostyczne zaimplementowane bezpośrednio w firmwarze układów procesujących dane trygerowe. Moduły te pozwalają podglądać dane płynące przez system, mierzyć częstość sygnałów z komór lub częstość znalezionych mionów, weryfikować poprawność transmisji danych, jak również wprowadzać do systemu dane testowe. Warszawa , 5 października 2009 Karol Buńkowski, UW

17 Monitoring podczas zbierania danych
Dedykowane aplikacje w czasie rzeczywistym odczytują dane diagnostyczne z systemu trygera, analizują je i w graficznej postaci prezentują wyniki Monitorowanie statusu elektroniki: periodyczny odczyt rejestrów informujących czy układy elektroniczne działają poprawnie, sprawdzanie wartości liczników błędów transmisji  natychmiastowa informacja dla zbierających dane o ewentualnych problemach w elektronice trygera Monitorowanie danych płynących przez system: Sygnały z komór oraz znalezione miony są zliczane przez moduły histogramujące zaimplementowane w układach trygera. Na tej podstawie obliczana jest średnia oraz chwilowa ich częstość  natychmiastowa informacja dla zbierających dane o jakości działania komór RPC, jakości działania systemu trygera PAC, poprawności konfiguracji systemu, Monitorowanie systemu trygera podczas zbierania danych jest wykonywane przez dedykowane aplikacje które na bieżąco odczytują dane diagnostyczne z elektroniki trygera, analizują je i w graficznej postaci prezentują wyniki. Można wyróżnić dwa rodzaje monitoringu. Pierwszy to monitorowanie statusu elektroniki. Daje on natychmiastową informację dla osób nadzorujących system o ewentualnych problemach w elektronice trygera. Drugi rodzaj monitoringu to monitorowanie danych płynących przez system. Sygnały z komór oraz znalezione miony są zliczane przez moduły histogramujące zaimplementowane w układach trygera. Na tej podstawie obliczana jest średnia oraz chwilowa częstość tych sygnałów. Na tej podstawie osoby nadzorujące zbieranie danych mogą na bieżąco dowiedzieć się o jakości działania komór i systemu trygera. Warszawa , 5 października 2009 Karol Buńkowski, UW

18 Monitoring trygera – częstość 4 wyjściowych mionów (beczka)
Monitoring online Monitoring działania komór RPC na podstawie wielokanałowych liczników z LB Częstość sygnałów (szum + miony) czas paski Wyniki monitoringu przedstawiane są na – między innymi - takich oto obrazkach, tworzonych w czasie rzeczywistym przez oprogramowanie kontrolne. Górne obrazy to monitoring komór RPC. W link boardach sygnały z każdego paska są zliczane przez moduły histogramujące, wyniki tych zliczeń są odczytywane co 10 sekund. Następnie dla każdej komory obliczany jest chwilowa częstość sygnałów i prezentowana na wykresie w zależności od czasu. Dodatkowo prezentowana jest średnia częstość sygnałów dla każdego paska oddzielnie. W ten sposób na bieżąco można ocenić czy komora w ogóle działa, czy nie szumi za bardzo, czy nie łapie zakłóceń (wówczas pojawiają się piki na wykresach). Dolny obrazek to monitoring wyjścia systemu trygera RPC, czyli częstość znalezionych mionów. Kolejne linie to częstość przypadków z przynajmniej jednym, dwoma, trzema i czterema mionami względem czasu. Częstość mionów Monitoring trygera – częstość 4 wyjściowych mionów (beczka) Warszawa , 5 października 2009 Karol Buńkowski, UW

19 Synchronizacja systemu trygera
Czyli Problem jednoczesności zdarzeń w praktyce Czyli „Zsynchronizujmy zegarki” Teraz chciałbym przejść do drugiego z zagadnień omawianych w mojej pracy, czyli do synchronizacji systemu trygera RPC. Można powiedzieć, że jest to znany z fizyki relatywistycznej problem jednoczesności zdarzeń w praktyce. Dwóch komandosów tuż przed akcją: - Ok. Zsynchronizujmy zegarki! Ja mam 12:00. - Ja mam za dwie No dobra... Poczekamy te dwie minuty... Warszawa , 5 października 2009 Karol Buńkowski, UW

20 Synchronizacja systemu trygera (1)
1 ns · c = 0,3 m 14m = 42ns 4.2m = 14ns Ale na czym polega problem? Otóż mimo iż miony wylatujące z punktu zderzenia poruszają się prawie z prędkością światła, to detektor jest na tyle duży, że różnice w czasie lotu mionów do różnych komór są większe niż czas pomiędzy kolejnymi zderzeniami. Jeszcze większe są różnice w czasie propagacji sygnałów po kablach z komór do Link Board-ów, różnice te sięgają 70 ns. A przecież aby zidentyfikować mion, musimy mieć koincydencję sygnałów z komór od tego właśnie mionu w 25 ns. Bo jak przypominam, mionów szukamy oddzielnie dla każdego przecięcia, następującego co 25 ns. Sygnały z komory niesie informację o czasie przejścia mionu przez komorą z dokładnością kilku ns. Różnice w czasie lotu mionów do różnych komór > 25 ns Jeszcze większe różnice w czasie propagacji sygnałów z komór do Link Board-ów (od 33 do 107 ns) A przecież w PACach chcemy mieć koincydencję sygnałów w 25 ns! Warszawa , 5 października 2009 Karol Buńkowski, UW

21 Synchronizacja systemu trygera (2)
W Link Boardach sygnały z pasków są najpierw synchronizowane do zegara 40 MHz („kwantyzacja czasowa”) przy pomocy „okienka synchronizacyjnego”. Następnie dodatkowo opóźniane o wybraną całkowitą liczbę taktów zegara. Pozycja okienka synchronizacyjnego i opóźnienie danych (inne dla każdego LB): Zerowe przybliżenie – obliczone na podstawie symulacji czasu lotu mionów Poprawki z analizy zebranych danych (metoda jest podany w pracy) Cel: na wyjściu wszystkich Link Boardów sygnały pochodzące od mionów z tego samego przecięcia pojawiają się dokładnie w tym samym momencie (25 ns). Tak więc sygnały z komór muszą zostać odpowiednio wyrównane w czasie, co jest wykonywana jest w Link Boardach. Asynchroniczne sygnały z pasków są najpierw synchronizowane do 40 MHz zegara sterującego elektroniką, a następnie mogą być dodatkowo opóźnione o całkowitą liczbę taktów zegara. W ten sposób sygnały z komór są przypisywane do odpowiedniego numeru przecięcia wiązek. Cel jest taki, aby na wyjściu wszystkich Link Boardów sygnały pochodzące od mionów z tego samego przecięcia pojawiły się dokładnie w tym samym momencie (25 ns). Ale aby osiągnąć ten cel trzeba odpowiednio ustawić pozycje okienek synchronizacyjnych oraz wartości opóźnień. W zerowym przybliżeniu pozycje okienek synchronizacyjnych i wartości opóźnień można obliczyć na podstawie czasu lotu mionów do poszczególnych komór. Natomiast poprawki do parametrów można znaleźć analizując zebrane dane. W swojej pracy podałem metodę zarówno tych obliczeń jak i analiz. Warszawa , 5 października 2009 Karol Buńkowski, UW

22 Synchronizacja sygnałów RPC- miony kosmiczne
Procedura synchronizacji została przetestowana dla mionów kosmicznych: Parametry zostały policzone dla mionów lecących pionowo z góry Po zebraniu danych obliczono poprawki do pozycji okienka synchronizacyjnego, analizując rozkłady BX-ów sygnałów względem BX-u trygera BX – numer kolejnego przecięcia paczek Sygnały ze wszystkich komór jednego koła po poprawkach Tryger Procedura ta została przetestowana dla mionów kosmicznych. Parametry synchronizacyjne zostały policzone dla mionów lecących pionowo z góry i zaaplikowane w Link Boardach. Po zebraniu danych obliczono poprawki do pozycji okienek synchronizacyjnych. Wyniki, czyli te właśnie poprawki dla poszczególnych Link Boardów, pokazuje ten wykres. Widać, ze poprawki te nie przekraczają zazwyczaj 5 ns, Poprawki te są pod kontrolą a cała procedura synchronizacji jest zbieżna. Dane za wcześnie Dane za późno Poprawka do pozycji okienka synchronizacyjnego dla poszczególnych LB BX sygnału z komory względem BX-u trygera Warszawa , 5 października 2009 Karol Buńkowski, UW

23 Podsumowanie System kontroli, diagnostyki i monitorowania zapewnia właściwe działanie trygera RPC PAC. Procedura synchronizacji trygera RPC PAC została pozytywnie zweryfikowana dla mionów kosmicznych. System trygera RPC PAC działa i oczekuje na start LHC. Warszawa , 5 października 2009 Karol Buńkowski, UW

24 Warszawa , 5 października 2009
Karol Buńkowski, UW

25 Efektywość trygera vs 
Warszawa , 5 października 2009 Karol Buńkowski, UW

26 Efektywość trygera vs φ
Warszawa , 5 października 2009 Karol Buńkowski, UW

27 Częstość trygera Warszawa , 5 października 2009 Karol Buńkowski, UW

28 Synchronizacja systemu trygera (3)
Jak wyznaczyć „ten sam moment”? „Układem odniesienia” jest zegar 40 MHz, synchroniczny z wiązką. Początek układu wyznacza sygnał startujący odliczanie przecięć (czyli taktów zegara). Na odbiornikach odpowiednio opóźniany, aby skompensować różnice w długościach światłowodów dystrybuowane do wszystkich płyt z jednego miejsca (system TTC podłączony do LHC). Transmisja LB – TB - kompensacja różnic w długości światłowodów: Dane transmitowane do TB są oznaczane na LB numerem przecięcia. Na TB dane są opóźniane tak, aby numer przecięcia otrzymany z danymi pasował do lokalnego numeru na TB Warszawa , 5 października 2009 Karol Buńkowski, UW

29 To the Global Muon Trigger
Tryger mionowy RPC PAC Detector Counting room Control & diagnostic LVDS cables Link Board Synchronization Unit & LMUX Trigger Board Ghost Buster & Sorter SYNCH. & LDMUX PAC GB & Sorter Optic Links GHz 1104 fibers PAC To the Global Muon Trigger 1232 Link Boards in 96 Boxes, Steered by Control Boards PAC FEB Data Concentrator Card Resistive Plate Chambers RMB FEB Pudełka z bakelitu wypełnione gazem, sygnał odczytywany przez miedziane paski: szerokość: 0.5 – 4 cm, długość: cm 84 Trigger Boards in 12 Trigger Crates Co to Counting room System wykinany w warszawie To Data Acquisition Algorytm identyfikacji mionów (PAttern Comparator): koincydencja czasowa sygnałów z kilku komór, Sygnały z komór są porównywane do predefiniowanych wzorców przestrzennych torów mionów. Wzorce odpowiadają mionom o rożnym pT Od 4 do 6 warstw komór otaczających punkt zderzeń 480 komór w beczce, 504 w pokrywach ~ pasków Warszawa , 5 października 2009 Karol Buńkowski, UW

30 RPC - Resistive Plate Chambers
Detektor gazowy, zoptymalizowany do detekcji mionów w warunkach CMSu Podwójna wnęka gazowa (szerokość: 2 mm) ze wspólnymi paskami odczytowymi Napięcie zasilające ~9.5 kV Komory pracują w ograniczonym modzie lawinowym: mniejsze wzmocnienie gazowe (~ ) + wzmacniacz elektroniczny Paski odczytowe: szerokość: 0.5 – 4 cm, długość: cm Mieszanka gazowa: 96.2% C2H2F4, 3.5% isoC4H10, 0.3% SF6 Rozdzielczość czasowa ~ 1 ns Efektywność > 95% Szum ~5 Hz cm2 (bakelit poolejowany) Odporność na wysoką częstość cząstek (do 1000 Hz/cm2) readout strips bakelite HV - + isolator graphite 2 mm  C2H2F4- Tetrafluoroetan (nazwa kodowa: R-134a,) freon isoC4H10 isobutan SF6 Komory pracują w ogranoczonym modzie lawinowym, wzmocnienie gazowe ~ ) A significant improvement is achieved by operating the chambers in the so-called avalanche mode: the electric field across the gap (and consequently the gas amplification) is reduced and robust signal amplification is introduced at the front-end level. The substantial reduction of the charge produced in the gap increases by more than one order of magnitude the hit rate that the RPC can sustain (up to 1000 Hz/cm2) Warszawa , 5 października 2009 Karol Buńkowski, UW

31 Warszawa , 5 października 2009
Karol Buńkowski, UW

32 Czasu lotu mionu do komory (z symulacji)
Sygnał wyjściowy okienko LB1 opóźnienie 25ns Czas lotu Czas propagacji LB2 LB3 zderzenie czas Optymalną pozycję okienek i opóźnienia dla danych można obliczyć dla każdego LB z: Czasu lotu mionu do komory (z symulacji) Czasu propagacji sygnałów po kablach z RPC do LB: winOpeni = (timin + iTTC + offset) % 25 ns didata = a – int[(timin + offset)/25ns] + bi - (1*) + ciwin + (2SM) następnie poprawić na podstawie analizy zebranych danych Warszawa , 5 października 2009 Karol Buńkowski, UW

33 Produkcja i rozpad higgsa