Developing #210
Updated by Vitaliy Schetinin over 6 years ago
<p>DigiBuilder</p>
<p>DigiBuilder является интрефейсом для чтения файлов экспериментальных данных - результатов работы библиотеки https://github.com/evovch/ACCULINNA_go4_user_library.<br />
А точнее файлов, появляющихся после этапа Calibration: https://github.com/evovch/ACCULINNA_go4_user_library/blob/master/docu/DAQ_ER_diagram2.pdf.<br />
На этом этапе данные представлены в виде root дерева, в ветках которого лежат объекты класса CalDetMessage <st,stch,calval>.</st,stch,calval></p> <st,stCh,calVal>.</p>
<p>В рамках этой задачи предлагается научить DigiBuilder работать с CalDetMessage только от телескопов и бимдет. Остальные детекторы будут добавлены в последующих задачах.<br />
Надо обкатать схему.</p>
<p>DigiBuilder должен быть наследником FairSource и реализован по примеру https://github.com/ExpertRootGroup/er/blob/dev/beamtime/ERRootSource.h .<br />
Простое чтение событий из внешнего файла с помощью fTree->GetEntry();<br />
Запуск происходит с помощью FairRunOnline.</p>
<p>В результате работы должен получаться root файл в ветках которого лежат диджи.<br />
На данный момент для каждого детектора реализован свой диджи, более того, реализованы диджи для разных типов станций детектора (для телескопа отдельно для Si и отдельно для CsI):</p>
<p>https://github.com/ExpertRootGroup/er/blob/dev/telescope/data/ERQTelescopeCsIDigi.h<br />
https://github.com/ExpertRootGroup/er/blob/dev/telescope/data/ERQTelescopeSiDigi.h</p>
<p>https://github.com/ExpertRootGroup/er/blob/dev/BeamDet/data/ERBeamDetMWPCDigi.h<br />
https://github.com/ExpertRootGroup/er/blob/dev/BeamDet/data/ERBeamDetTOFDigi.h</p>
<p>Такой подход живет с давних времени и вызван тем, что адресация digi реализована по разному для разных типов станций и хранится в самом диджи:<br />
К примеру для ToF это fToFNb, а для MWPC это (fMWPCNb + fPlaneNb + fWireNb)</p>
<p>На данный момент для большинства детекторов мы от такого подхода уходим и вся адресация digi, кроме номера канала внутри станции хранится в названии ветки. см Рис.<br />
В связи с этим будет введен один базовый класс диджи содержащий в себе <ch,time,amp> <ch,Time,Amp> и в редких случаях будут создаваться его наследники.<br />
Структура классов еще не переделана.<br />
ВНИМАНИЕ: Не надо ее переделывать в рамках этой задачи. Это будет сделано сразу во всем репозитории в рамках другой задачи и ветки.</ch,time,amp></p> ветки.</p>
<p>В рамках данной задачи для каждого типа детектора и станции в нем в ветку надо складывать объект соответсвующего класса. Тем более, что этот механизм нам пригодится для редких случаев наследников базового класса диджи.</p>
<p>Название ветки для телескопа формируется как ERQTelescope[Si,CsI]Digi_<telescope_name>_<station_name>_[X|Y-для ERQTelescope[Si,CsI]Digi_<Telescope_name>_<Station_name>_[X|Y-для односторонних станций, XY|YX - для двухсторонних]_[номер станции данного типа(односторонней или двусторонней)]_[X|Y в случе двусторонней]</station_name></telescope_name></p> двусторонней]</p>
<p>Station_name - берется из базы данных: https://github.com/ExpertRootGroup/er/blob/dev/db/QTelescope/QTelescopeParts.xml<br />
Фактически является идентификатором конкретной железки и поэтому должно быть уникальным. (На картинке это не так, поправим)</p>
<p>Название ветки для BeamDet формируется как BeamDet[MWPC|ToF]Digi[ToFNb |X MWPCNb | Y MWPCNb].</p>
<p>Фактически сейчас для каждого детектора применяется своя система именования ветки. Это порочно, надо от этого уходить.</p>
<p>Предлагаю ввести название ветки по формату: <detector_type: beamdet=""><detector_name: left="" telescope=""><station_name>[Detector_type]_[Detector_name]_[Station_name]_[адресация данного детектора]<detector based="" setup=""></detector></station_name></detector_name:></detector_type:></p> <Detector_type: BeamDet, QTelescope, RTelescope, ND, Gadast>_<Detector_name: Left telescope, Gadast старый, ND красивый>_<Station_name>_<detector/setup based адресация [TofNb | MWPCNb_[X|Y] | TelescopeStationNb_[X|Y-для односторонних станций, XY|YX - для двухсторонних]_[X|Y в случе двусторонней]></p>
<p>Так что не надо ориентироваться на те названия веток, что сейчас выдают диджитизаторы. Давайте кашерные названия веток сформируем в рамках данной задачи, остальное подстроим потом.</p>
<p>Также предлагаю начать пользоваться системой Folders FairRoot, чтобы ввести группировки веток для удобства дальнейшего использования. Например:</p>
<p>Detector_type<br />
Detector_name<br />
Station_name<br />
...</p>
<p>Это поможет алгоритмам реконструкции проще искать группы веток с которыми необходимо совершать операции.<br />
Station_name должна быть уникальной и браться из xml базы данных железок.</p>
<p>Так как, что именно пишется со станции: только время, амплитуда и время или что то еще... Информация об этом должна быть представлена в setup.xml файле.<br />
В дальнейшем мы научим DigiBuilder сохранять эту информацию в FairRunTimeDB с помощью классов типа QTelescopeSetup, BeamDetSetup и т.д, которые ответственны предоставлять классам реконструкции интерфейсы к данной информации. НО не в рамках этой задачи!</p>
<p>Программисткая часть:</p>
<p>ACCULINNA_go4_user_library должна уметь инсталиться:<br />
./compile.sh должен принимать как параметр install_prefix<br />
Лучше, если процедура сборки будет оформлена с помощью cmake. sh скрипты - не тру.<br />
И после make install или типо того, в указанной install директории<br />
должны создаваться директории:</p>
<p>includes/<br />
lib/</p>
<p>cmake процедура er научится работь с флагом -DACCULINNA_go4_user_library='install директория'<br />
по которому будет создавать переменные:<br />
ACCULINNA_go4_user_library_INCLUDES<br />
ACCULINNA_go4_user_library_LIBS<br />
Добавлять их в config.sh<br />
И только в случае наличия этого флага компилить DigiBuilder.</p>
<p>Класс DigiBuilder должен находиться в директории beamtime.</p>
<p>DigiBuilder является интрефейсом для чтения файлов экспериментальных данных - результатов работы библиотеки https://github.com/evovch/ACCULINNA_go4_user_library.<br />
А точнее файлов, появляющихся после этапа Calibration: https://github.com/evovch/ACCULINNA_go4_user_library/blob/master/docu/DAQ_ER_diagram2.pdf.<br />
На этом этапе данные представлены в виде root дерева, в ветках которого лежат объекты класса CalDetMessage <st,stch,calval>.</st,stch,calval></p> <st,stCh,calVal>.</p>
<p>В рамках этой задачи предлагается научить DigiBuilder работать с CalDetMessage только от телескопов и бимдет. Остальные детекторы будут добавлены в последующих задачах.<br />
Надо обкатать схему.</p>
<p>DigiBuilder должен быть наследником FairSource и реализован по примеру https://github.com/ExpertRootGroup/er/blob/dev/beamtime/ERRootSource.h .<br />
Простое чтение событий из внешнего файла с помощью fTree->GetEntry();<br />
Запуск происходит с помощью FairRunOnline.</p>
<p>В результате работы должен получаться root файл в ветках которого лежат диджи.<br />
На данный момент для каждого детектора реализован свой диджи, более того, реализованы диджи для разных типов станций детектора (для телескопа отдельно для Si и отдельно для CsI):</p>
<p>https://github.com/ExpertRootGroup/er/blob/dev/telescope/data/ERQTelescopeCsIDigi.h<br />
https://github.com/ExpertRootGroup/er/blob/dev/telescope/data/ERQTelescopeSiDigi.h</p>
<p>https://github.com/ExpertRootGroup/er/blob/dev/BeamDet/data/ERBeamDetMWPCDigi.h<br />
https://github.com/ExpertRootGroup/er/blob/dev/BeamDet/data/ERBeamDetTOFDigi.h</p>
<p>Такой подход живет с давних времени и вызван тем, что адресация digi реализована по разному для разных типов станций и хранится в самом диджи:<br />
К примеру для ToF это fToFNb, а для MWPC это (fMWPCNb + fPlaneNb + fWireNb)</p>
<p>На данный момент для большинства детекторов мы от такого подхода уходим и вся адресация digi, кроме номера канала внутри станции хранится в названии ветки. см Рис.<br />
В связи с этим будет введен один базовый класс диджи содержащий в себе <ch,time,amp> <ch,Time,Amp> и в редких случаях будут создаваться его наследники.<br />
Структура классов еще не переделана.<br />
ВНИМАНИЕ: Не надо ее переделывать в рамках этой задачи. Это будет сделано сразу во всем репозитории в рамках другой задачи и ветки.</ch,time,amp></p> ветки.</p>
<p>В рамках данной задачи для каждого типа детектора и станции в нем в ветку надо складывать объект соответсвующего класса. Тем более, что этот механизм нам пригодится для редких случаев наследников базового класса диджи.</p>
<p>Название ветки для телескопа формируется как ERQTelescope[Si,CsI]Digi_<telescope_name>_<station_name>_[X|Y-для ERQTelescope[Si,CsI]Digi_<Telescope_name>_<Station_name>_[X|Y-для односторонних станций, XY|YX - для двухсторонних]_[номер станции данного типа(односторонней или двусторонней)]_[X|Y в случе двусторонней]</station_name></telescope_name></p> двусторонней]</p>
<p>Station_name - берется из базы данных: https://github.com/ExpertRootGroup/er/blob/dev/db/QTelescope/QTelescopeParts.xml<br />
Фактически является идентификатором конкретной железки и поэтому должно быть уникальным. (На картинке это не так, поправим)</p>
<p>Название ветки для BeamDet формируется как BeamDet[MWPC|ToF]Digi[ToFNb |X MWPCNb | Y MWPCNb].</p>
<p>Фактически сейчас для каждого детектора применяется своя система именования ветки. Это порочно, надо от этого уходить.</p>
<p>Предлагаю ввести название ветки по формату: <detector_type: beamdet=""><detector_name: left="" telescope=""><station_name>[Detector_type]_[Detector_name]_[Station_name]_[адресация данного детектора]<detector based="" setup=""></detector></station_name></detector_name:></detector_type:></p> <Detector_type: BeamDet, QTelescope, RTelescope, ND, Gadast>_<Detector_name: Left telescope, Gadast старый, ND красивый>_<Station_name>_<detector/setup based адресация [TofNb | MWPCNb_[X|Y] | TelescopeStationNb_[X|Y-для односторонних станций, XY|YX - для двухсторонних]_[X|Y в случе двусторонней]></p>
<p>Так что не надо ориентироваться на те названия веток, что сейчас выдают диджитизаторы. Давайте кашерные названия веток сформируем в рамках данной задачи, остальное подстроим потом.</p>
<p>Также предлагаю начать пользоваться системой Folders FairRoot, чтобы ввести группировки веток для удобства дальнейшего использования. Например:</p>
<p>Detector_type<br />
Detector_name<br />
Station_name<br />
...</p>
<p>Это поможет алгоритмам реконструкции проще искать группы веток с которыми необходимо совершать операции.<br />
Station_name должна быть уникальной и браться из xml базы данных железок.</p>
<p>Так как, что именно пишется со станции: только время, амплитуда и время или что то еще... Информация об этом должна быть представлена в setup.xml файле.<br />
В дальнейшем мы научим DigiBuilder сохранять эту информацию в FairRunTimeDB с помощью классов типа QTelescopeSetup, BeamDetSetup и т.д, которые ответственны предоставлять классам реконструкции интерфейсы к данной информации. НО не в рамках этой задачи!</p>
<p>Программисткая часть:</p>
<p>ACCULINNA_go4_user_library должна уметь инсталиться:<br />
./compile.sh должен принимать как параметр install_prefix<br />
Лучше, если процедура сборки будет оформлена с помощью cmake. sh скрипты - не тру.<br />
И после make install или типо того, в указанной install директории<br />
должны создаваться директории:</p>
<p>includes/<br />
lib/</p>
<p>cmake процедура er научится работь с флагом -DACCULINNA_go4_user_library='install директория'<br />
по которому будет создавать переменные:<br />
ACCULINNA_go4_user_library_INCLUDES<br />
ACCULINNA_go4_user_library_LIBS<br />
Добавлять их в config.sh<br />
И только в случае наличия этого флага компилить DigiBuilder.</p>
<p>Класс DigiBuilder должен находиться в директории beamtime.</p>