EXPERT ROOT

Могу сказать только, что в рпедыдущих геометриях именно такоя нумерация и была

Мой вопрос к Егору и  Виталику. Господа программисты, объясните мне где разумная граница между универсальностью и простотой.  Мы хотим иметь нойрад дижитайзер конкретно под вупертальский прототип, или реалистично иметь  универсальный для других геометрий тоже.  Что меня смущает сейчас. В dev/NeuRad/ERNeuRad.cxx заданы переменные:  Int_t pixel_in_submodule_X = 4;  Int_t pixel_in_submodule_Y = 4;  Int_t submodule_in_module_X = 2;   Int_t submodule_in_module_Y = 2; В тоже время в dev/macro/geo/create_NeuRad_Wupper_Proto_geo.C эти же переменные захардкожены циферками в строках 113-127 примерно так: for (UInt_t iX=0; iX4; iX++). Как правильно делать в текущий момент?

Я сейчас над этим работаю. Вижу два пути.

1. Параллельно с геометрией формировать сопроводительный файл (типа geopar), в котором в каком-то machine-friendly виде закодирована структура геометрии. То есть написано, сколько модулей, сколько субмодулей, сколько пикселей, и т.д. Далее этот par файл легко читается специально отведённым классом (я так понимаю, задумка была, что это делает ERNewRadSetup?) и делаются соответствующие действия в симуляции, дижитизации или где-либо ещё.

2. Очевидно, нужно ещё посидеть и развить эту мысль, но в целом идея следующая. Мы задаёмся какими-то ограничениями (скажем, иерархией) и пишем где нужно некоторый код, который анализирует GeoManager считает количество дочерних узлов на разных уровнях и проверяет имена. Я сейчас это делаю. В классе ERNeuRad больше не будет конкретно захардкоженных кол-ва чего-то в чём-то. Это будет вытаскиваться прям из GeoManager'а.

ERNeuRad - это только симуляция. Мы уже, вроде бы, определились, что от симуляции через ERNeuRadPoint передаётся два числа - номер ФЭУ и номер канала ФЭУ. Если я правильно понимаю, дижитизации тогда не нужно обращаться к геометрии - нужно только к таблицам в digi.par? (но это не точно)

1. Единственное ограничение на геометрию - ее структура(иерархия). Количество копий на каждом уровне и праметры шейпов это вариативно. Если задаемся структурой то все остальное действительно нужно считывать с помощью gGeoManger. За это действительно отвечает класс ERNeuRadSetup. Захардкодены были только субмодули введенные недавно. Просто не было временного ресурса это нормально перенести в ERNeuRadSetup. Доставание всех остальных парметров уже было реализовано (так что не надо тут Америку переоткрывать).

2. В диджитизации нужно представление о геометрии. К примеру длина файбера для расчета затухания. Все тоже тянется из Setup. Также как и параметры электроники.

3.Я смотрю меняется нумерация объемов. У меня ноль бвл слева сверху. Это осознано?

по поводу положения начала счета пикселей, я просил перевернуть на 180 градусов ту систему, которая реализована в документации к ФЭУ. Это сделано для тго, чтобы ось y была направлена вверх.  Если нет возражений, я бы так и оставил, как Егор сейчас сделал. 

Появилась материца кросстолков 5x5. Можно пару слов об этом?

Да, я попросил Егора это ввести, поскольку есть ощущение, что в эксперимнетальных данных зажигается в целом большее число пикселей, чем в симуляциях. Я хочу проверитть  гипотезу активного перетекания света между файберами, принадлежащими разным пикселям. Это странно, поскольку по мнениюю Андрея Безбаха, все файберы были обмазаны белым а потом черным.  Вот формулировка: Просьба добавить  еще и кросс- толк  по 1% в каждого из "внучатых"  соседей.

Похоже, для понимания экспериментальных данных это существенно. Получится:

1  1    1    1  1
1  4.5 4.5 4.5  1
1  4.5   * 4.5  1
1  4.5 4.5 4.5  1
1  1    1    1  1
 

Пока ждет.  Как только мы закончим с подготовкой эксперимнета h5, надеюсь, сядем с Иваном, Егором и Вратиком, проведем ревизию того, что есть и двинемсяя к получению результатоав для статьи.