EXPERT ROOT

Как определять вероятность, отличную от единицы, если не попадаем в промежутки по tof или dE?

2) Что такое объект fProjectile?

Вопросы про объекты отпали, до меня дошло.

А вот про вероятность до сих по не понял. Если она нулевая при непопадании в границы, то зачем интерфейс на порог по вероятности.

Она либо 1, либо 0. Более сложные вещи будем потом имплементировать. Если попали в заданную область значения - 1, если нет, то 0

Для идентификации нужны данные и с этапа диджитизации для dE и tof, а и с этапа определения параметров трека для получения вектора импульса.

Как одновременно в симуляции получить и то и другое? 

Не совсем понял, что значит в симуляции. Но на этапе FairTask досутупны все ветки, которые были во входных файлах (основном  можно ще дополнительные добавлять. AddFriend()) и во всех предыдущих задачах. Через ioman

Оговорка, хотел написать в макросе вместо симуляции.

В ioman есть только приватный метод AddFriends().

Сейчас делаю fRun->AddFriend("reco.root"), но у меня падает программа на моменте получения значения угла из объекта трека.

Не могу понять с чем связано. То ли неправильно считывается объект из дерева, то ли просто напутал со ссылками и указателями при вытаскивании данных из объекта fBeamdetTrack.

Во первых проблема была не втом, что ты не правильно работаешь с фалами, а то , что таск BeamDetPID ожидает, что объект BeamDetTrack был создан. Но это происходит не всегда.

Тут на самом деле вскрылась довольно большая проблема, которая заключается в том, что мы не можем прекратить выполнение PipeLine из какого либо таска. Сейчас отбор событий у нас происходит с помощью MarkFill(kFALSE), который говорит не писать событие в выходной файл. Но при этом все последующие таски в ране будут выполняться. Это порочно, потому что в следующих тасках мы должны спрашивать был ли создан такой то объект. При этом мы даже не можем на текущий момент опросить состояние флага, который ставится с помощью MarkFill(kFALSE), просто нет такого интерфейса.

Данная ситуация видимо создана по причине того, что FairRoot предпологает, что отбор событий был совершен на этапе дака. Такой вывод я сделал, потому что cbmroot и r3broot не используют MarkFill. То есть у них количество событий на входе всегда равно количеству событий на выходе. Наша действительность немного другая и отбор событий происходит уже в анализе.

На данный момент я просто добавил в ERBeamDetPID проверку на существование объекта ERBeamTrack и все перестало падать. Кроме того, я добавил пример макроса с AddFriend.

Я вижу два пути развития событий:

1) Я ошибаюсь на счет FairRoot и все таки найдется нативный способ остановки pipeline и перехода к следующему событию. Решается написанием письма Радеку

2) Я перегружу менеджеры FairRunAna. Будет ERRunAna, который умеет останавливать PipeLine и переходить к следующему событию.

Если у нас несколько тасков в одном макросе, то у нас событие обрабатывается всеми тасками, а потом осуществляется переход к следующему событию - правильно, а не так, что сначала прогоняется вся диджитизация, потом поиск трека и т.д?

Да. Сначала обрабатывается всеми тасками

У меня неправильно было задано имя BeamDetTrack в ioman в классе ERBeamDetPID! Сейчас нормально все работает и без проверки существования объекта. 

Ну это проблемы не решает. Буду писать свой ран менеджер с блэкджеком.

Я попробовал использовать G4IonTable как калькулятор массы иона по разным наборам параметров. И понял, что это не возможно, потому что Geant оже хочет инициализации кучи своих объектов. Так что вывод простой. На этапе реконструкции пользователь сам задает все необходимое для идентификации. В данном случае надо просто добавить интерфейс для ввода массы.

Каким образом гарантировать, что масса пользовательского иона равна в симуляции и реконструкции?

Только разумностью пользователя

Как можно в одном дереве получить результаты и симуляции и реконструкции? Чтобы можно было в TreeViewer проверить качество восстановления координаты на мишени.