EXPERT ROOT

Единственное замечание, в паре Detecor type, Detector name надо  позаботиться о длине названий веток, чтоб их было легко анализровать.

Поэтому  Telescope_LeftTelescope... (Detector_type= Telescope, Detector_name = LeftTelescope) кажется избыточно длинным.

Как-то надо покороче Tlscp_LeftT, например. 

Просьбы

1) В макрос digibuilder.С(NEvents) добавить возможность обработки нескольких файлов, схожих по имени, либо сразу целой папки с файлами.
Сделать так, чтобы, если NEvents не задан, то обрабатываются все события input файлов.

2) Добавить отдельную задачу, где мы будем общаться о том, какие отборы сейчас применяются в digibuilder и в reco. 

3) Добавить кластеризацию MWPC (высчитывать координату в MWPC как среднее арифметическое номеров зажжённых проволочек, если это проволочки рядом)

1) MWPCtimes: временные данные в ветках, относящихся к MWPC (например BeamDetMWPCDigiX1.fTime), не переводятся в наносекунды. Нужно умножать значение времени на 0.125

2) ERQTelescopeSiDigi_Left_telescope_SingleSi_SQ300_X_0.fTime не калибруются, нужно умножать значение на 0.3

3) ERQTelescopeCsIDigi_Left_telescope_CsI_L_0.fTime пишутся только нули.

4)ERQTelescopeCsIDigi_Right_telescope_CsI_R_0.fTime пишутся только нули

5) На данный момент, после конвертации lmd->root с помощью последней версии егоровской библиотеки в ветку DetEventCommon.trigger пишется значение триггера. Нужно, чтобы ER тоже записывал это значение.

В таске ERBeamDetUnpack.cxx строки 129-134 допускают, что в digi.root будут события, где не записалось время MWPC, а только амплитуды. Нам такие события не нужны, их можно выбрасывать.

1) Добавил значение триггера в выходной файл digibuilder. https://github.com/ExpertRootGroup/er/commit/04f520cd04dc58d6dcdad34bbe0332799fb7912f

См. ветку EventHeader.fTrigger

Обрати внимание на необходимость добавить в макрос строки:

 ERBeamTimeEventHeader* header = new ERBeamTimeEventHeader();
 run->SetEventHeader(header);

2) Добавил временные калибровки и в MWPC и в телескопы. https://github.com/ExpertRootGroup/er/commit/6329d3f51367a9db5399087d08ae5bae91ead218

3) Поправил все логи. Теперь ничего не пишется во время обработки. Только если включить DEBUG уровень логов. https://github.com/ExpertRootGroup/er/commit/9c997397ba232b917c3e12ce852dee6980e68ef1

По поводу отборов.Добавил возможность UserCut в Digibilder и расширил в ERRunAna.

Что это значит? В er можно процессить не все события во входном файле. А только те, которые прошли Cut.

В случае DigiBuilder в макросе это выглядит так:

builder->SetUserCut("Beam_detector_F3.@fDetMessages.GetEntriesFast() == 4");

Строка в скобках? на самом деле? полноценный рутовский объект типо TCut. То есть туда прямо в макросе можно добавить и Graphical Cut и написать, в принципе, любое выражение, которое мы пишем в tree->Draw("",cut)

Предвкушая вопрос про @: это тоже нативный рутовский синтаксис, позволяющий обратиться к объекту коллекции в дереве. Так что здесь я сразу отфильтровал события, в которых почему то амплитуд в F3 меньше, чем 4. Таких кстати много

Таким образом можно длеать отборы до digibuilder прямо на сырых данных.

Можно делать отборы после дижибилдер в макросе реконструкции, к примеру так:

run->SetUserCut("EventHeader.fTrigger==1");

Пользуйтест, пожалуйста.

Забыл. Чтобы заработало, нодо подождать пока Егор примет https://github.com/evovch/ACCULINNA_go4_user_library/pull/19

Обновить AccDaq master, обновить er 210_digibuilder

Сделать так, чтобы при запуске digibuilder, reco в терминал выводился прогресс обработки. Каждые 10000 событий вывод о том, сколько событий обработано из скольки, либо какой процент всех событий обработан. 

Необходимо добавить функционал распараллеливания макросов digibuilder и reco на несколько потоков

Для нормальной обработки данных необходимо делать отборы по событиям. на данный момент этот функционал крайне неудобен.
Моё предложение - создать несколько веток, в которые можно будет записывать некие индикаторы, флаги, для разных отборов. 
То есть при выполнении выбранного условия, значению соответствующего флага присваивать TRUE.
Флагов должно быть достаточно много

нужно сделать так, чтобы Cut' ы не резали количество событий, а чтобы для событий которые не прошли отбор, TClonnesArray не заполнялись.
То есть если события не удовлетворяет хоть одному условию, то во всех ветках, размер TClonesArray равен 0. 

На данный момент, в методе Bool_t ERTelescopeUnpack::ApplyCalibration калибровка значений времени делается следующим образом: https://github.com/ExpertRootGroup/er/blob/b491ec622a863692eaa615292831c91524bcd754/beamtime/unpack/ERTelescopeUnpack.cxx#L317

Небходимо изменить метод калибровки времён. Нужно сделать что-то аналогичное амплитудам. В макроcе должен сообщаться путь к файлу с калибровочными параметрами. В файле будет находиться два столбца с калибровочными параметрами (par1 par2). Параметры используются для линейной калибровки следующим образом:
Time(ns) = time(channel)*par1 + par2

Для всех кремниевых станций, как и для амплитуд, так и для времён будут свои калибровочные параметры.

Привет! Обнаружилось небольшое неудобство метода ERTelescopeUnpack::ReadCalFile
При данном алгоритме считывания столбцов в элементы обьекта TMatrixD вижу слудующее: если в текстовом файле второй столбец не заканчивается ровно на последней цифре числа, а есть ещё какой нибудь отступ от него, то возникает ошибка со следующим сообщением: 
[FATAL  ] [23.11.2018 11:11:49] [ERTelescopeUnpack.cxx::ReadCalFile:300] Wrong file format in 

Это терпимо, но причиняет небольшую боль, так как файлы приходится ровнять вручную.

Ivan Muzalevsky wrote:

На данный момент, в методе Bool_t ERTelescopeUnpack::ApplyCalibration калибровка значений времени делается следующим образом: https://github.com/ExpertRootGroup/er/blob/b491ec622a863692eaa615292831c91524bcd754/beamtime/unpack/ERTelescopeUnpack.cxx#L317

Небходимо изменить метод калибровки времён. Нужно сделать что-то аналогичное амплитудам. В макроcе должен сообщаться путь к файлу с калибровочными параметрами. В файле будет находиться два столбца с калибровочными параметрами (par1 par2). Параметры используются для линейной калибровки следующим образом:
Time(ns) = time(channel)*par1 + par2

Для всех кремниевых станций, как и для амплитуд, так и для времён будут свои калибровочные параметры.

Сделано

Иван, давай скомпонуем текущий список доработок в digibuilder:

На данный момент из этой переписки я вижу следующие:

1. Сделать так, чтобы при запуске digibuilder, reco в терминал выводился прогресс обработки. Каждые 10000 событий вывод о том, сколько событий обработано из скольки, либо какой процент всех событий обработан. 

2. Необходимо добавить функционал распараллеливания макросов digibuilder и reco на несколько потоков

3. Набор претензий к тому, как устроены отборы.

Два вопроса:

1. Это весь список?

2. В чем конкретно претензии к отборам? Желательно на конкретном use case.

При использовании UserCut выяснилось следующее:

Если данное событие не прошло условия отбора, то хотя размер всех TClonesArray оказыватеся равен 0, значение триггера тем не менее заполняется значениями, предположительно равным значению триггера в последнем "нормальном" событии. (событие прошедшее отбор UserCut). Нужно как то пофиксить этот баг, либо не заполнять совсем, либо заполнять бессмысленным значением. 
Также нужно позволить пользователю самому выбирать опции сохранять количество событий после digibuilder или резать, при использовании UserCut

Поправил.

1. Когда событие не проходит кат, тригер в его EventHeader заполняется -1:

https://github.com/ExpertRootGroup/er/commit/f078dbc2610c760b18c3f19dabed8a2e9e68a60c

2. В методе ERDigibuilder::SetUserCut введен второй параметр -  опция fFillSkippedEvents.
По умолчанию она true и событие, которое не проходит кат, попадает в выходной файл с пустыми TClonesArray.
Если опция false: 

builder->SetUserCut("Beam_detector_F3.@fDetMessages.GetEntriesFast() == 4",kFALSE);

Событие в выходной файл не попадет. Будет разное количество событий во входном и выходном файле.

https://github.com/ExpertRootGroup/er/commit/0e13f326e2fb520868bab0a1a509ca9e19875e74