Podstawy symulacji

Podstawy symulacji w eksperymentach wysokich energii

W przypadku eksperymentów wysokich energii bazujących na FairROOT symulacje są zwykle podzielone na etapy i taski. Etapy symbolizują poszczególne stadia procesu rejestracji cząstek, zaś tzw. taski symbolizują poszczególne stadia procesu rejestracji ale (zwykle) w jednym subdetektorze. W opisie będę się trzymał konwencji używanej w eksperymencie CBM. Tutaj rekonstrukcja przebiega w następujących etapach:

• transport - na tym etapie wkładamy cząstki wyprodukowanie przez jakiś model np. UrQMD do detektora, następnie używane jest środowisko do tzw. transportu (Geant 3 lub 4). Geant symuluje jak propagują się cząstki w detektorze - przez które elementy detektora przelecą, ile energii w takim detektorze zostawią itd. Makro transportujące zawiera klasę FairRunSim - do niej dodawane są informacje o detektorach i polu magnetycznym (jest to dostateczna informacja by zasymulować transport). Informacje z transportu przechowywane są w formie tzw. "punktów MC" będących (zwykle) utożsamianych z pojedynczym oddziaływaniem cząstki z detektorem.
• digityzacja - to symulacja reakcji detektorów na sygnał, który jest wyznaczany na podstawie punktów MC, dane tego typu zapisywane są w formie tzw. digitów/digisów a klasy do tego typu obliczeń to tzw. digitizery
• klasteryzacja - to etap poszukiwania klastrów digitów tj. grupy sąsiadujących digitów. Jest to pierwszy etap symulacji taki sam zarówno dla "czystych symulacji MC" jak i dla rzeczywistych danych.
• produkcja hitów - to odtwarzanie hitów na podstawie klastrów, hit można tu (nie jest to ścisłe) utożsamiać ze zrekonstruowanym punktem-MC
• rekonstrukcja cząstek, zderzeń, bazując na hitach odtwarza się trajektorie/właściwości cząstek oraz zderzenia

Stosowana tu konwencja jest dosyć umowna, w zależności od subdetektora czy eksperymentu, może się np. zdarzyć że po digityzacji bezpośrednio produkuje się hity, również terminologia jest różna - czasem punkt MC nazywany jest hitem, a klaster jest wejściem dla algorytmów rekonstrukcji cząstek.

MPD

Makra do symulacji w MpdROOT znajdują się w katalogu macro/mpd, do transportu służy makro runMC.C zaś do pozostałych etapów rekonstrukcji macro reco.C. Na co należy zwrócić uwagę przy pierwszym uruchamianiu runMC.C?

• po pierwsze na to czy używany Geanta 3 lub 4 (należy odpowiednio zmienić dyrektywę na początku makra)
• na użyty generator (wybór również następuje przez dyrektywy), runMC pozwala wybrać dyrektywami jeden generator, w ogólności możemy dodać kilka generatorów do symulacji - po prostu zderzenie będzie wtedy superpozycją danych z kliku takich generatorów
• następnie mamy metodę geometry_stage1, jest ona dostarczana z zewnętrznego makra i definiuje jakie subdetektory będą użyte w symulacji
• konfiguracja FairPrimaryGenerator, jest to klasa która odpowiada za to w którym miejscu będą miały miejsce zderzenia - czy np. w środku detektora czy na jego obrzeżach
• konfigurację pola magnetycznego (czy jest używane stałe pole czy z tzw. mapy tj. bardziej realistyczne)
• FairRunSim::SetStoreTraj(kTRUE) włącza zapisywanie tzw. geotracków. Geotracki są używane aby wizualizować trajektorie w tzw. Event Display. Same geotracki zajmują bardzo dużo miejsca więc zapisuje się je tylko w ostateczności.
• ustawienia FairTrajFilter określają które cząstki będą zapisywane w postaci geotracków a co za tym idzie wizualizowane (czy np. tylko pierwotne albo tylko wtórne, z jakim krokiem symulacji itd.)

CBM

W przypadku CbmROOT proces symulacji wygląda podobnie, nie jest on jednak dokładnie taki sami:

• runMC.C jest zastąpione przez run_transport.C, chociaż ustawiamy tutaj te same flagi co należy zwrócić uwagę że w CBM nie używa się bezpośrednio FairRunSim a CbmTransport do zarządzania symulacją. Ważne jest wybranie odpowiedniego "setupName" czyli geometrii detektora dostępne to:
  
  • sis100_electron
  • sis100_electron_sts_long
  • sis100_hadron
  • sis100_hadron_sts_long
  • sisi100_muon_jpsi_sts_long
  • sis100_muon_jpsi
  • sis100_muon_lmvm_sts_long
  • sis100_muon_lmvm
• reco.C zostało rozbite na makra run_digi.C oraz run_reco_event.C
• makra znajdują się macro/run

W przypadku CBM-u należy również pamiętać o tym, że mamy kilka możliwych konfiguracji detektora, oraz dwa możliwe tryby zbierania danych. Tutaj podałem nazwy makr do rekonstrukcji event by event - tzn. każde zderzenie jest symulowane osobno. Możliwa jest natomiast symulacja w tzw. timeslice'ach symulujących ciągłe zbieranie danych - wynika to z faktu, że CBM będzie zbierał dane ponad tysiąc  razy szybciej niż MPD. Obecnie jednak symulacja w tym trybie działa "średnio". Symulacje w timeslice wymagają zmiany parametru sEvBuildRaw - pusty oznacza symulacje "event by event", "Ideal" to idealny "event builder" a "Real" to realistyczny event builder (ciągle w fazie rozwoju).

Dane CBM-u można następnie skompresować przy pomocy makra run_analysis_tree_maker, makro to zapisuje dane "do analizy" posiadają one inną strukturę i są znacznie okroje względem danych z mark transport, digi i reco.