EXPERT ROOT

Как я понял, нужно еще создать класс ERBeamDetSetup.

Какие у него должны быть атрибуты?

Не. Он нужен для реконструкции дальнейщей.

А макрос то добавь, которым ты все это тестировал. Можешь посмотреть на маркрос NeuRad_digi в macro/NeuRad

Да, в диджитизации Setup класс нужен, когда мы используем файлы параметров. Здесь пока их нет. А вот в макросе нойрада есть. Когда будешь копировать не забудь удалить логику которая включает загрузку дополнительных текстовых файлов параметров:

  TString NeuRadDetDigiFile = gSystem->Getenv("VMCWORKDIR");
  NeuRadDetDigiFile += "/parameters/NeuRad.digi.v4.par";
  parInput1->open(NeuRadDetDigiFile.Data(),"in");

Хорошо, это учту когда доберусь до макроса.

Я не понял, как правильно использовать digi->AddLink(FairLink("BeamDetTofPoint",iPoint)).  Должно же быть несколько поинтов, из которых форируется один digi?

Внутри Exec() диджитизатора проходим по коллекции поинтов как в ERRTelescopeHitFinder, сравниваем энергию с порговой:

Float_t eloss = gRandom->Gaus(point->GetEnergyLoss(), fElossDispersion);
   if (eloss  fElossThreshold) continue;

и получается, что просто не записываем в digi все, что меньше порога. В каком месте делать ликовку поинтов?  

0) Ну да в ERRTelescopeHitFinder пока ошибка, но там не страшно это из физики. Хотя я поправлю в ближайшее время. И он должен называться дигитайзер тоже.

1) У нас к одному считывающему объему подключен один проводок. На нем появится суммарный сигнал от всех энерговыделений в этом чувствительном объеме. Поэтому да, нужно отсортировать поинты по проволочкам (для MWPC), и их энергию просуммировать. А время взять как время самого первого.

2) Как видно из пункта 1, на один dig может приходится несколько поинтов. Информация об этом нам нужна при анализе. К примеру если мы захотим узнать какие треки сформировали этот digi. Для этого есть механизм линков. Первый аргумент AddLink это назвнание ветки в root файлах которое задается в Register. В этих ветках мы же храним TClonesArray, то есть массив объектов. Вот второй аргумент это номер объекта в этом TClonesArray. Тот по которому ты с помощью At(index) достаешь оттуда его. Это механизм кстати позволяет вешать на линки веса и сворачивать многоуровневые линки. К примеру дальше мы будем выстраивать такую цепь points

Закончил примерно тоже самое для QTelescope. Можно подсмотреть: https://github.com/ExpertRootGroup/er/blob/dev/telescope/ERQTelescopeDigitizer.cxx

1) Как  и можно ли вообще сделать так, чтобы в digi был номер события?

Можно, но не нужно.

1) Номер события можно достать из io менеджера таким образом ioman->GetEntryNr(). (а он сам синглетон - FairRootManager* ioman = FairRootManager::Instance();)

2) В выходном файле всегда есть атрибут fEventID в MCEventHeader, если используется FairRunSim или fMCEntryNo в EventHeader, если используется FairRunAna

Для анализа трекинга MWPC с помощью TreeViewer нужно чтобы в качестве entry было событие, а не диджи. Должно быть 4 ветки, в каждой из которых лежат только диджи для одной из плоскостей. 

При этом вроде бы терятся смысл коллекции диджи. Можешь как-то это прокомментировать? 

В далеком и светлом будущем у нас будут методы работы c MWPC со множественностью больше 1.