Developing #65
BeamDet поиск трека
Status: | Закрыта | Start date: | 07/21/2017 | |
---|---|---|---|---|
Priority: | Низкий | Due date: | ||
Assignee: | Mikhail Kozlov | % Done: | 0% | |
Category: | BeamDet | |||
Target version: | v-0.4 |
Description
Необходимо разработать класс ERBeamDetTrackFinder, унаследованный от FairTask. Задача класса - создание объекта ERBeamDetTrack по данным на MWPC станциях.
Предпологаем, что события с множественностью больше единицы мы убрали на этапе диджитизации. То есть в коллекции MWPCDigi должно быть 4 элемента. digi должны принадлежать разным станциям. Это надо проверить и в противном случае кинуть сообщение.
ERBeamDetTrack будет состоять из трех точек в пространстве. две из них получены из MWPC, третья из предположения, что трек прямолинеен и знания координаты мишени. (fX1,fY1, ... fZ2, fXt, fYt, fZt t - target)
Так как мы занем, что ERBeamDetTrack точно один в событии, его не надо хранить как один элемент в TClonesArray. Интерфейс
ioman->Register("BeamDetTrack.", "BeamDet track", fBeamTrack, kTRUE); позволяет хранить одиночные объекты, наследованные от TNamed. Обрати внимание на точку в конце названия ветки. Она необходима для корректной работы TBrowser.
Знания о геометрии детектора необходимо инкапсулировать в отдельный класс - ERBeamDetSetup(см ERNeuRadSetup). Туда же нужно убрать процедуру получения по номеру проволочки координаты в пространстве. Одной из ключевых фишек FairRunTimeDB является то, что она записывает в par.root геометрию текущей симуляции. Оттуда мы ее достаем к примеру в eventDisplay. Во время одиджитизации и любой другой задачи геометрия также доступна через глобальный указатель gGeoManager. В NeuRad видно как по нему можно определить всю текущую геометрию исходя только из преполодения о том как объемы вложены друг в друга и как называются. Таким образом мы избавляемся от зависимости кода от текущей конфигурации детектора.
Туда же потом будут инкапсулированы занания о электронике на каждом канале считывания. Как это сейчас сделано в NeuRad. Но это потом.
History
#1 Updated by Vitaliy Schetinin over 7 years ago
Посмотрел файлы от которых ты решил отталкиваться. Обрати внимание, что в данном случае мы пропускаем такую сущность как хит. Которвя была актуальна в muSi.
#2 Updated by Vitaliy Schetinin over 7 years ago
Ржавый алгоритм,который раньше делал эту логику описыавется так:
1) Он просто по номеру проволочки востанавливает четыре отдельные координаты: xmw1, ymw1, xmw2, ymw2.
2) Дальше собирает из них две точки в пространстве:
VmwFa(xmw1,ymw1,0)
VmwCl(xmw2,ymw2,растояние между MWPC)
3) Формирует вектор пучка
Vbeam = VmwCl - VmwFa
4) Есть координата Zdist
Zdist = MWclosDist - header->UpMat.MWXYdist/2.;
Если я правильно понял это середина отрезка между X и Y плоскостями ближайшей к мишени MWPC
5) Координаты на мишени:
xbt = xmw2 - Zdist*tan(Vbeam.Theta())*cos(Vbeam.Phi());
ybt = ymw2 - Zdist*tan(Vbeam.Theta())*sin(Vbeam.Phi());
То есть он вообще никак не учитывает то, что у нас еть смещение пучка между станциями X и Y. Ок. Это вроде также как обсуждали в последний раз.
6) Отбор событий, попавших в мишень. Я думаю нам его тоже стоит сделать и не писать события не попавшие.
Как не писать события в выходной файл можно посмотреть в BeamDetCalibratorNew. FairRun->MarkFill()
#3 Updated by Vitaliy Schetinin over 7 years ago
- Status changed from Открыта to Закрыта