Obecnie produkcja danych w CBM jest zarządzana przez pliki yaml i specjalne skrypty. Generalnie produkcja przebiega w kilku etapach:
- transport - czyli symulacja przy pomocy Geanta tego jak cząstki się propagują w materiale detektora
- digitalizacja - jest to symulowanie odpowiedzi detektora na depozycję energii przez cząstki z poprzedniego kroku
- rekonstrukcja - to odnajdowanie trajektorii cząstek na podstawie sygnału z digitizacji
- konwersja do AnalysisTree - jest to format danych używany do analiz fizycznych
Makra i skrypt znajduja się w katalogu macro/PWG/common/production. W celu symulacji uruchamia się skrypt run_json.sh z parametrem config.json, który tworzy odpowiednie skrypty. Skrypty te są wysyłane następnie na farmę. Z punktu widzenia "typowego użytkownika" należy edytować plik config.json gdyż tam znajdują się główne parametry symulacji. Poniżej tabela z głównymi ustawieniami pliku konfiguracyjnego. Pogrubioną czcionką te pola, które relatywnie często mogą się zmieniać (bo np. chcemy użyć nietypowego pola do zapisu danych, makra do transportu z innego miejsca niż to z domyślnym makrem do transportu itp.).
| Nod | Nod | Nod | Opis |
| accesorry | batch | jeśli true to wysyłaj joby na klaster | |
| nEvents | liczba eventów | ||
| jobRange | zakres jobów | ||
| ram | ilość RAM-u potrzebna do symulacji, jeśli damy za mało job się może wywalić na jakimś makrze | ||
| partition | rodzaj kolejki na klastrze, zwykle definiuje maksymalne dostępne zasoby | ||
| time | maksymalny czas jobu, jeśli job trwa dłużej zostanie zakończony | ||
| logDir | miejsce do przechowywania logów | ||
| cbmRoot | ścieżka do skryptu ustawiającego zmienne środowiskowe CbmROOTa | ||
| jobScript | ścieżka do skryptu, który jest wysyłany (może wymagać zmiany jeśli nie uruchamiamy z podkatalogu cbmroota) | ||
| transport | run | jeśli tak uruchom transport | |
| macro | ścieżka do makra transportującego | ||
| digitzation | run | jeśli tak uruchom digitizację | |
| macro | ścieżka do makra digitizującego | ||
| reconstruction | run | jeśli tak uruchom rekonstrucję | |
| macro | ścieżka do makra rekonstruującego | ||
| AT | run | jeśli tak konwertuj do AnalysisTree | |
| macro | makro do konwersji | ||
| transport | input | generator | rodzaj danych wejściowych |
| file | dane z generatora (uwaga: możemy mieć kilka generatorów na raz) - ścieżka do pliku z danym z generatora MC | ||
| output | path | miejsce gdzie dane będą zapisane | |
| overwrite | jeśli tak nadpisz | ||
| target | ustawienia tarczy | ||
| digitization | eventMode | digitizacja, jeśli prawdziwe digitalizacja w trybie zderzenie po zderzeniu | |
| timeSliceLenght | długość timeslice'a (potrzebne w symulacji ciągłej) | ||
| input | wejście (plik wyjściowy z transportu) | ||
| output | wyjście | ||
| reconstruction | rawFile | wejście (plik wyjściowy z digitizacji) | |
| nTimeSlices | liczba timesliceów | ||
| output | wyjście | ||
| sEvBuildRaw | rodzaj event buildera | ||
| traFiles | wyjście z transportu | ||
| AT | traFiles | wyjście z transportu | |
| rawFile | dane z digiziera (wyjście z digitizera) | ||
| recFile | dane zrekonstruowane (wyjście z rekonsruckji) | ||
| unigenFile | wejscie do transportu (dane z generatora MC) | ||
| output | wyjście |
Należy uważać na niektóre wartości, które wpisujemy w pola. Przykładowo często używane są zmienne środowiskowe (np. \${USER} albo \${VMCWORKDIR}), dodatkowo skrypt wstawia swoje zmienne np. \${taskId}. \${taskId} jest nadpisywana dla poszczególnych jobów - tzn. jest swego rodzaju numerem porządkowym (w końcu nie chcemy puszczać symulacji na 200 komputerach, które zapisują do tych samych plików).
Trzeba też uważać na rodzaj symulacji. W CBM mamy dwa rodzaje symulacji:
- event by event - to najstarszy i dosyć sprawdzony rodzaj symulacji. Zakłada się tutaj że częstotliwość zderzeń jest na tyle nieduża że CBM może zaczynać zbieranie danych, gdy zacznie się kolizja i kończy gdy ostatnia wyprodukowana cząstka wyleci z detektora. Jest to typowy tryb zbierania danych dla większości współczesnych eksperymentów.
- timeslice - to nowszy rodzaj symulacji. Tutaj zakłada się zbieranie danych ciągłe (tak jak to będzie w rzeczywistości w CBM). To oznacza że detektor ciągle zbiera dane i grupuje je w ramki czasowe (tzw. timeslice). W jednym timeslice może być wiele eventów. Nie mamy tu więc jasnego rozróżnienia pomiędzy poszczególnymi kolizjami i teoretycznie może się zdarzyć że cząstka powstała w jednym zderzeniu zostanie przypisana do kolejnego zderzenia. Jest to tryb symulacji, który jest obecnie mocno rozwijany toteż może czasem się wysypywać. Dlatego zalecam zacząć od symulacji event by event.
Niektóre parametry pliku konfiguracyjnego mogą generować konflikty np. ja zauważyłem że storeAllTimeslices oraz StartTime powinny być usunięte w symulacji event by event. Możliwe że, w kolejnych wersjach pojawia się nowe parametry.