Open ladamczy opened 6 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 .
W danych mam poprawne wartości, zakomentowanie correctedRpEvent nie pomogło
A czy metody
getMagneticField() getZDCEastRate()
działaja poprawnie?
wydaje mi się że magnetic field działa poprawnie, ale nie jestem pewna EastRate:
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 ?
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ą.
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)?
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.
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?
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.
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.
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?
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.
Fity niech Pan robi w zakresie 0.46-0.53 tak jak w selekcji kV0. To też może dać jakieś ułamki procenta.
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.
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:
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.
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?
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 ?
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.
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.
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żć
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.
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, ....
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:
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.