Несколько раз вставал вопрос, нужна ли централизация, должна ли система в целом обечить возможность экспериментов (различные калибровки, изменения в модулях), или такие опыты не должны выходить за пределы домашней директории каждого пользователя. База данных калибровок Обсуждение началось с вопроса, может ли в базе данных для какого-либо интервала времени (событий) лежать несколько калибровок. Если нет, то библиотеки для доступа существенно упрощаются. Для BGO сохранялись все калибровки, но возврата к более старым не было ни разу. С другой стороны, тем, кто создает калибровки, возможность экспериментировать с разными версиями просто необходима. Для этого предложено вводить калибровку другого типа. До этого под типом понимался формат, уникальный для каждой части детектора, но который может меняться со временем для одной системы. Разработка библиотеки для доступа к калибровкам приостановлена из-за сессии, но Ваня пообещал разослать пример API. CVS Реальных шагов по его внедрению еще не сделано. Бурная дискуссия велась по поводу ветвей (branch). Они позволяют вносить изменения, не затрагивая основную версию. Ветвь может затем объединится со "стволом" либо забыта. Проблема состоит в том, что в надстройке СНД, которую мы собираемся использовать, ветви запрещены. Было высказано мнение, что если модулю требуется серьезная переделка, то разумнее создать отдельный модуль. Таким образом можно облегчить параллельное существование, например, двух разных алгоритмов восстановления треков. Off-line Система, которая разрабатывается для СНД выглядит привлекательно, но есть желание ее изменить. Во-первых, совершенно искусственно выглядит использование языка Python. Почему бы не воспользоваться ROOT и CINT? C++ учить все равно придется, да и модулями удобнее будет управлять. Применение Python оправдывает то, что эта часть уже успешно работает. Во-вторых, хочется нарушить последовательное расположение модулей при обработке события. Непонятно, удастся ли локализовать в одном модуле итерационные алгоритмы для сшивки треков и кластеров. Блоки упорядочиваются один раз, и нельзя, обработав часть события, установить путь, по которому данные пойдут дальше. Может стоит отказаться от блока управления модулями? В-третьих, наши коллеги вообще не собираются использовать ROOT. Встал вопрос о том, какую политику избрать нам. Перекодировать готовые файлы не лудший выход. Можно ли свободно переключать модули, отвечающие за ввод и вывод, и каждому выбирать удобный формат? Что такое упомянутый Букиным абстрактный гистограммный пакет? Дальнейшие планы План-график, ставший результатом обсуждения, должен опубликовать Ваня. Одна из проблем в том, что перед выбором архитектуры on- и off-line систем, хочется услышать Кроковного и Роота. Перечень оборудования, которое необходимо закупить в течение следующего года, тоже должен вскоре появиться в минимальном и полноценном вариантах. Закупать его надо, чтобы можно было реально с ним работать, хотя подождав, можно будет за те же деньги купить больше и лучше. С оборудованием тоже много вопросов. Можно ли запускать на одном компьютере задачи, обеспечивающие медленный контроль, визуализацию, обработку потока данных с детектора. К каждой системе свои требования, поэтому разумно выглядит разделить и оптимизировать конфигурацию hard & soft для каждой задачи. Максим Никулин