użycie nowych dane ze śladami globalnymi

ladamczy commented 6 months ago

Utworzyłem nowe dane dla 9 ranów. Dane znajduja sie w BNL

/star/u/adamczyk/pwd/picoUPC/test_upcdst/nnnnnnnn/nnnnnnnn.root gdzie nnnnnnnn to numer runu

Trzeba sprawdzić czy macie Państwo jakieś problemy z czytaniem tych plików.

Utworzyłem również nowa biblioteke star-upc-new zawiera ona modyfikacje dwóch klas: StUPCEvent, StUPCTrack

StUPCEvent ma cztery nowe metody getBeamXPosition(),getBeamYPosition(), getBeamXSlope(), getBeamXSlope() które zwracają pozycje wiązki dla danego przypadku. Nie bedzie już potrzeby używania (czasami niejednoznacznej) fukkcji zwracajacej pozycje wiązki na podstawie numeru fillu.

StUPCTrack ma rozszerzona palete flag dla danego sladu: kV0 to ślady dodane z picoDST spełniajace warunki preselekcji V0 kCEP to pewna klasa śladów globalnych które nie sa stowarzyszone z żadnym werteksem. One sa potrzebne Tomasowi do wyznaczenia wydajności werteksowania. Nas one nie interesuja.

Czyli wszystkie ślady które maja kV0==true || kCEP==true zostały dopisane do naszych danych. Te sladu które maja not. (kV0==true || kCEP==true) sa tymi które juz w danych mieliśmy wcześniej.

Uwaga: część śladów majacych (kV0==true || kCEP==true) była i jest nadal wśród śaldów które nie maja (kV0==true || kCEP==true) powinny to być slady z kPrimary==true.

Zatem od teraz (aby mieć pewność że nie mamy śladów-dublerów) będziemy używać tylko sladów z kV0==true Wypada jednak sprawdzić że cały proces tworzenia nowych danych jest poprawny. Sprawdzalismy to z Tomasem ale zawsze cos jeszcze mozecie wykryć. Zatem prosiłbym o stosowne testy:

Czy Wasze obecne programy działaja na nowych danych (nawet bez nowej biblioteki i nowych funkcjonalnosci)
Czy ilość K0 utworzonych ze sladów z flagą kV0 == true jest zawsze większa lub równa od ilości K0 utworzonych ze sladów z kV0==false && kCEP==false
Ewentualnie czy liczba K0 utworzonych ze sladów z flagą kV0 == true && kPrimary==true jest dokładnie taka jak ilość K0 utworzonych ze sladów z kV0==false && kCEP==false
Mile widziany rozkład decayLengthHypo() dla K0 i Lambd ze śladów z kV0==true oraz tych z kV0==false && kCEP==false

Przypomne jedynie że do preselekcji (ustawienia flagi kV0 ) wymagaliśmy cięć: NHits>=15 pt>0.15 |eta|<1.1 pary o sumie ładunków 0 dcaDaughters() < 2.0 && DCABeamLine() < 2.0 && (pointingAngleHypo()>0.9 || decayLengthHypo()<3.0) abs(K0.m()-0.495) < 0.035. || abs(Lambda.m()-1.115) < 0.015 || abs(Lambdabar.m()-1.115) < 0.015

Zatem do selekcji kandydatów na V0 i porównań powinnismy uzywac conajmniej tak restrykcyjnych cieć. Nominalnie mamy bardziej restrykcyje ciecia (oprócz cięć na masy) i takie bardziej restrykcyje cięcia powinny być użyte do testów.

Zaczniemy teraz produkowac wieksze próbki (na poczatek około 10% statystyki) ale jakakolwiek informacja od Państwa o problemach/różnicach będzie bardzo pomocna aby proces zatrzymać, poprawić błedy i puścić od nowa. Jest to dla Państwa obecnie priorytet (poza ewentualna prezentacją Pani Patrycji na poniedziałek). Pani Patrycja oczywiscie ma zbyt mała próbke do testów przypadków ekskluzywnych ale moze użyć programu do tag&&probe wydajności ToF. Pan Adam może użyć nominalnego swojego programu.

Prosze tutaj raportować złe i dobre wieści o nowych danych.

ladamczy commented 4 months ago

Czy aby na pewno w tych plikach jest gałąź o nazwie "correctedRpEvent"

chain->SetBranchAddress("correctedRpEvent", &rpEvt);

może by to zakomentowac do tego testu .

PatrycjaMalinowska commented 4 months ago

W danych mam poprawne wartości, zakomentowanie correctedRpEvent nie pomogło

ladamczy commented 4 months ago

A czy metody

getMagneticField() getZDCEastRate()

działaja poprawnie?

PatrycjaMalinowska commented 4 months ago

wydaje mi się że magnetic field działa poprawnie, ale nie jestem pewna EastRate:

ladamczy commented 4 months ago

wyglada na to jakby w obszarze pamięci gdzie powinien być BeamXPosition jest EastRate. Było by tak jakby Pani użyła nowej klasy UPCEvent do czytania starych danych. Rozumiem że tak nie jest i problem jest przy próbie czytanie nowych danych przy użyciu nowej klasy UPCEvent.

Do czytania starych danych używamy starej klasy UPCEvent.

Nowa i stara klasa jest odpowiednio w bibliotece star-upc-new i star-upc . Czy tutaj nie mieszaja sie Pani biblioteki/klasy UPCEvent ?

PatrycjaMalinowska commented 4 months ago

już jest dobrze, dziękuję za pomoc. W pliku building.sh miałam zmienioną klasę na nową star-upc-new, ale wykonywałam komendę w terminalu >> export LD_LIBRARY_PATH=../star-upc/build/:$ROOTSYS/lib << ze starą klasą.

AddahDraggon commented 4 months ago

Czy wymaganie podczas preselekcji aby w przypadku były co najmniej 2 dobre ślady z flagą kV0 może jakoś rzutować na wykresy otrzymane ze śladów gdzie jest wymagane (kV0==false && kCEP==false)?

ladamczy commented 4 months ago

Teoretycznie nie, ponieważ dwa dobre ślady z (kV0==false && kCEP==false) skopiowane z upcDST powinny mieć swoje kopie z picoDST z flagą kV0==true o ile ślady z picoDST przeszły naszą preselekcje.

Jedyna mozliwością braku konsystencji będzie sytuacja gdy selekcja którą Pan robi w swojej analizie będzie mniej restrykcyjna niż preselekcja. Ale wtedy powinniśmy obserwowac odwrotny efekt niz widzimy. Czyli więcej przypadków w starych danych.

Potencjalnym źródłem problemu może być obliczanie pozycji beamline. W starych danych mamy funkcje od Patrycji a w nowych danych mamy wartości bezpośrednio z bazy danych. Proponuje aby Pan dla nowych danych użył funkcji od Patrycji albo w kazdej z trzech produkcji wymusić beamline(0,0,0,0)

Niezaleznie od powyższego prosze sobie wziąść jeden run i wypisać numery przypadków (powiedzmy 100) które mają K0 z flagami (kV0==false && kCEP==false) a nastepnie sprawdzi dlaczego w starych danych dla tych samych przypadków nie widzimy 10% przypadków. Czy danego przypadku nie ma w staryxh danych czy jest a jeśli jest to które ciecie go usuwa.

AddahDraggon commented 4 months ago

Okazało się, że dla nowych danych aplikowałem Afterburner dwukrotnie - po poprawieniu okazuje się że stare dane mają więcej wykryć niż nowe. Sprawdziłem cięcia, one są bardziej restrykcyjne niż preselekcja - jedyna rzecz jaka odróżnia cięcia w starych danych od cięć w nowych danych jest wymaganie aby te 2 dobre ślady miały flagę kV0. Czy między starymi danymi a nowymi danymi było coś zmieniane w ich pozyskiwaniu? W sensie widziałem dyskusję odnośnie nowego muDst chyba, więc chciałbym się upewnić. Chciałbym również zapytać, czy dobrze rozumiem że w każdym przypadku ze starych danych każdy ślad powinien istnieć w nowych danych w dwóch kopiach, jednej z kV0==true i w drugiej z kV0==false && kCEP==false?

ladamczy commented 4 months ago

Wywołanie Afterburnera dwukrotnie nie powinno nic zmieniać. Afterburner startuje od poziomu który nie jest zmieniany przez afterburnera. Czy mógłby Pan pokazac jakiś plot ?

Oba zbiory danych pochdzą z tego samegi MuDst. Stare dane powstały bezpośrednio z MuDst a nowe dane powstały z połączenia starych danych i danych picoDST (które też powstały z tego samego MuDst).

Ostatnie stwierdzenie nie jest prawdziwe. Kazdy slad ze starych danych powinien być w nowych z flaga kV0==false && kCEP==false. Dodatkowo te stare ślady które "znajdą" jakikolwiek slad (również bez ToF) który spełnia warunek selekcji V0 będzie skopiowany i będzie miał flagę kV0.

AddahDraggon commented 4 months ago

Najpierw ustawiłem wszędzie beamline(0,0,0,0) (kod obecnie na Githubie to odzwierciedla), niewiele się zmieniło, potem skorygowałem ten problem z afterburnerem i obecnie to wygląda jak poniżej.

K0afterV0finder.pdf

Problem z Afterburnerem polegał na tym, że selekcja, którą napisałem żeby ją puścic w STARze, już posiadała Afterburnera. Po otrzymaniu nowych danych, aplikowałem własną, ostrzejszą selekcję, ponownie z Afterburnerem, efektywnie dając jakiekolwiek poprawki tam były dwukrotnie. Problem ten naprawiłem i wynik jest jak wyżej.

Czyli każdy stary ślad posiada kopię z kV0==false && kCEP==false, ale tylko niektóre posiadają kopię z kV0==true?

Uwaga: część śladów majacych (kV0==true || kCEP==true) była i jest nadal wśród śaldów które nie maja (kV0==true || kCEP==true) powinny to być slady z kPrimary==true.

Czy to coś oznacza w stosunku do flagi kPrimary (że powinniśmy/nie powinniśmy jej wymagać)?

Przypomne jedynie że do preselekcji (ustawienia flagi kV0 ) wymagaliśmy cięć: NHits>=15 pt>0.15 |eta|<1.1 pary o : sumie ładunków 0 dcaDaughters() < 2.0 && DCABeamLine() < 2.0 && (pointingAngleHypo()>0.9 || decayLengthHypo()<3.0) abs(K0.m()-0.495) < 0.035. || abs(Lambda.m()-1.115) < 0.015 || abs(Lambdabar.m()-1.115) < 0.015

Przedostatnie cięcie chyba jest bardziej restrykcyjne niż to obecnie stosowane? Czy oba ślady dostają flagę kV0 w momencie spełniania tych warunków? Czy ostatnie cięci efektywnie oznacza, że w każdym evencie powinienem widzieć przynajmniej jedno K0/Lambda0?

ladamczy commented 4 months ago

jestem zdziwiony problemem a afterburnerem w sensie kuumlowania poprawek. Nie mniej jednak jeśli podczas preseleckcj zapisał Pan kolekjce RP po afterburnerze to nie ma powodu poraz drugi wywoływać tej procedury.

Nowe dane maja ciecia

dcaDaughters() < 3.0 && DCABeamLine() < 2.5 && (pointingAngleHypo()>0.9 || decayLengthHypo()<3.0)

te bardziej restrykcyjne były tylko w tej pierwszej 10% testowej próbce.

Tak, każdy stary ślad posiada kopię z kV0==false && kCEP==false, ale tylko niektóre posiadają kopię z kV0==true

Flagi kPrimary nie powinniśmy nigdzie uzywać

Tak oba slady dostają flage kV0 .

Ostatnie ciecie nie oznacza że powinniśmy widzieć przynajmniej jedno K0. To jest selekcja śladow a nie przypadków.

Nadal sugeruje aby popatzrył Pan na kilka przypadków "ręcznie" ale teraz w dwrotnym kierunku. Prosze wyprintowac 200 przypadków które maja K0 w starych danych i sprawdzenie dla tych 200 przypadków nowych danych (przy selekcji starych danych). Powinien Pan zobaczyć 4-5 przypadków odrzuconych. Dlaczego ? Czy ich nie ma w nowej próbce czy jakieś ciecie (jakie) odrzuca taki przypadek.

ladamczy commented 4 months ago

Fity niech Pan robi w zakresie 0.46-0.53 tak jak w selekcji kV0. To też może dać jakieś ułamki procenta.

ladamczy commented 4 months ago

Wydaje mi sie że teraz jest konsystencja z wynikami Pani Patrycji która też widzi lekko wieksza licbe przypadków dla starycg danych. Pani również powinna sprawdzic te kilka przypadkówwięcej które Pani ma w starych danych. Dlaczego ich nie ma w nowych.

AddahDraggon commented 4 months ago

Z eventów z triggerem CPT wyizolowałem te które przechodzą analizę na starych śladach i nie przechodzą na nowych śladach - jest ich ok. 6000 i żaden z nich się nie pojawia w danych bezpośrednio z presleekcji - tzn. wydaje mi się, że przez to że w preselekcji żądam pary śladów z m.in. flagą kV0:

https://github.com/ladamczy/STAR-Analysis/blob/779b8456ad7f7bd3116db7303f2fb073d29fbbf9/Inclusive_Analysis/star-upc/src/master_deg_analysis/Wide_K0_search/STAR_Preselection.cxx#L238

która nie jest nadawana każdemu śladowi ze starych danych, ta preselekcja zwyczajnie część z nich ucina. Poprawiłem już kod na kV0==false&&kCEP==false, także można puszczać preselekcję ponownie.

ladamczy commented 4 months ago

po pierwsze nie widze w kodzie poprawek. Czy ten kod jest w repozytorium?

po drugie rozumiem że preselekcja kV0==false&&kCEP==false jest tylko do sprawdzenia że faktycznie dobre (stare) przypadki nie przeszły selekcji kV0. Do testu wolałbym wybrać jeden ran a nie wszystkie. Bo jesli okaże sie musimy robić od nowa procesing nowych danych to szkoda czasu na pełna preselekcje. Może Pan podac jeden run który wystaczy do testów?

ladamczy commented 4 months ago

jeszcze jedna uwaga w kodzie jest cos takiego jak goodQuality

Czy dobrze rozumiem, że jak znajdzie Pan przynajmniej jeden slad z liczba plaszczyzn <3 lub taki że jest tylko w jednej stacji to przypadek odrzucamy ?

AddahDraggon commented 4 months ago

Tak, jeśli z 2 śladów chociaż 1 nie ma 3 płaszczyzn lub dwóch stacji, to taki przypadek jest odrzucany. Run 18063120 ma sporo przypadków (1120) zaakceptowanych, także sądzę że się nada.

po drugie rozumiem że preselekcja kV0==false&&kCEP==false jest tylko do sprawdzenia

myślałem że skoro z żądaniem kV0==true nie dostajemy 100% starych danych to coś jest nie tak, ale chyba źle zrozumiałem, w sensie że my przechodzimy teraz całkowiciena nowe dane już z kV0==true?

Kod jest już poprawiony w repozytorium, i już skompilowałem pomyślnie program do sleekcji przypadków.

AddahDraggon commented 4 months ago

W jakich jednostkach funkcja getToFTime zwraca czas? Próbowałem tego szukać w kilku dokumentach i otrzymuję sprzeczne wartości w stylu 10ps, 25ps, 50ps.

AddahDraggon commented 3 months ago

Nie jestem pewien, ale czy wysyłałem numer runu do sprawdzenia zmodyfikowaną preselekcją czy problem faktycznie jest z żądaniem flagi kV0? Wydaje mi się że go wysyłałem ale nigdzie nie mogę znależć

ladamczy commented 2 months ago

teraz juz niestety nie w pełni pamietam co chcieliśmy zrobić. Czy potrzebujemy dla ranu 18063120 dane pełne bez preselekcji? Czy też potrzebujemy je po jakiejś nowej/innej preselekcji? Jesli tak to gdzie jest kod tej testowej preselkcji.

ladamczy commented 2 months ago

Ale generalnie to juz chyba nie czas na takie analizy. Pan musi napisac pracę i dobrze by było aby Pan przedstawił jakąś wersje do czytania do 10 czerwca, ....

ladamczy / STAR-Analysis

użycie nowych dane ze śladami globalnymi #19