Developing #65

BeamDet поиск трека

Added by Vitaliy Schetinin over 7 years ago. Updated over 7 years ago.

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 Закрыта

Also available in: Atom PDF