EXPERT ROOT

По текущему состоянию:

1) Этот детектор раньше назывался DSRD. Где то я забыл переименовать. Замени везде в коде этой папки DSRD на RTelescope.

2) В макросе симуляции поменяй, пожалуйста, геометрию на новыую версию; настрой генератор так, чтобы он размазывал направление полета немного по тета и от 0 до 360 по фи.

3) Сейчас в коде ProcessHits используются статические переменные. Это старый подход. По новому эти переменные стали атрибутами класса. Смотри как написано в документации и у Миши в BeamDet. И посмотри всю переписку по симуляции BeamDet(http://er.jinr.ru/develop/issues/56).

Посмотреть пример реализации детектора с двумя активными объёмами можно в Beamdet или Gadast

В классе симуляциии почему-то не запоминаем PDG частиц, вместо них масса. Так и должно быть?

Этот детектор сейчас унаследован не от ERDetector.  Нужно исправить?

Да. Это преобразованный очень старый класс. Его надо привести к стандартному виду. От BeamDet в итоге не будет отличаться.

Не совсем понимаю как реализовать такую форму кристалла CsI. Одними AddNode не  сделать ?

Каждый кристал можно собрать из двух примитивов TRD(тут смотреть параметризацию - https://geant4.web.cern.ch/geant4/G4UsersDocuments/UsersGuides/ForApplicationDeveloper/html/Detector/geomSolids.html).https://root.cern.ch/doc/master/classTGeoManager.html TGeoManager->MakeTrd1();

Эти примитивы нужно сложить с помощью булевской операции:https://root.cern.ch/doc/master/classTGeoCompositeShape.html

Залил геометрию

Выглядит здорово!

Я влил тебе в ветку все изменения из dev. Для того, чтобы было куда подсматривать. Обновись.

На данный момент по смиуляции нужно сделать следующее:

1) У нас будет два типа поинтов в RTelescope. Те что в силиконе и те, что в CsI. Нужно сделть два разных класса под них .Для этого переименнуй текущий в ERRTelescopeSiPoint. И создай класс ERRTelescopeCsIPoint.

2) По классу BeamDet/ERBeamDet.cxx можно отследить как работать в симуляции, когда у нас два типа чувствительных объемов.

а) Нужно зарегистрировать две ветки поинтов в выходном файле

б) Нужно ввести два чувствительных лобъема в CheckIfSensetive

в) Нужно сделать две функции типа AddPoint и вызывать ту, которая соответвует типу чувствительного объема в котором ты сейчас находишься.

г) У тебя были Sensor  и Sector для описания того, куда попала частица в силиконе. В случае CsI это просто номер кристала.

Уточнение по геометрии. Оказалось, что внешний радиус чувствительной области кремниевой пластины - 42 мм, а не 41.   Т.е.  16 активных колец заполняют радиусы от 16 мм до 42 мм

 Кроме того, вокруг и внутри чувствительной области есть пасивные кольца кремния. Снаружи от радиуса 42мм до радиуса 50мм  и изнутри от радиуса 15 мм до радиуса 16 мм. 

Cделал два типа поинтов и поправил геометрию.

Посмотрел. Тывсе правильно понял. И про геометрию и про два типа поинтов. Можно переходить к осознанию диджитизации

Я не получил майла по замечанию Вратислава. Поэтому залез и добавил watchers. См, пожалуйста, предыдущий коммент.

Олег, путаница скорее всего из-за того как введены чувствительные объемы. У тебя сейчас чувствительным названо все, что в своем имени имеет подстроки: sensor,sector,crystall. Но такие префиксы в геометрии v3 имеют не только предпологаемые чувствительные объемы, но и некоторые материнские к ним. Это может непредсказуемо отражаться на поведении метода ProcessHits. Для начала сделай более четкие отбор чувствительных объемов. К примеру добавь им в имя postfix sensitive.

Я поменял названия чувствительных объёмов в геометрии и ProcessHits, но ошибка в симуляции остаётся.

Vratislav Chudoba wrote:

Проверяв симмуляцию, нактнулся на нехорошую вещь. Она понятна из картинки в приложению (c1.gif и show_sim.C).

С помощью макроса RTelescope_sim_test.C в одном событии разыгриваются две частицы: протон с энергией 10 МэВ и альфа с энергией 70 МэВ. Видим, что обе частицы попадают в разыне места (как и было заложено в симмуляции), видим даже, что у них есть разные ID (пад 2 и 3). Когда строим сумарное выделение энергии в первом телескопе (протон должен остановиться в R1Si2, альфа в R1CsI) видим энергию около 80 МэВ (пад 4). Я бы ожидал увидеть точно 80 МэВ так как 70+10=80. Но если делаем отбор по сорту частицы, видим физически неправильную картинку. В паде 5 должны видеть 10 МэВ (но он пустой), а в паде 6 должно быть 70 МэВ.

Предполагаю, что проблема может быть связанна с (не)обнулением информации залитой в поинты во время итерации по одному событии. Или предполагалось, что в одном событию может быть только одна частица, а это неправильное предположение. Также напрыгает, что на 10 событий по 2 частицам видим всего лишь 20 поинтов. Наверно слишком высокие пороги для рождения вторичных частиц.

Вратислав:

1) В паде 5 ничего нет, потому что в RTelescope1CsIPoint.fELoss при RTelescope1CsIPoint.fPID меньше 3000 ничего нет. Протон остался в первых двух кремниях. Так работает Draw в случае хранения в ветках TClonesArray. Он строит только те entry в которых size каждой переменной Draw при применении условия больше нуля.

2) На eventDisplay я вижу, что альфа прошила весь setup насквозь. Это объясняет историю с шестым падом

После комментария от Сергея Геннадиевича о том, что если посчитать руками, то альфа должна остановиться в первом CsI, посмотрел еще раз. И увидел:

FairIonGenerator *ionGen = new FairIonGenerator(Z, A, Q, 1, 0., 0., momentumAlpha, xA, yA, zA);

Потом посмотрел тут: http://fairrootgroup.github.io/FairRoot/d9/dd3/classFairIonGenerator.html

И увидел:

px,py,pzMomentum components [GeV] per nucleon!

Поменял на:

FairIonGenerator *ionGen = new FairIonGenerator(Z, A, Q, 1, 0., 0., momentumAlpha/4, xA, yA, zA);

И альфа остановилась в первом CsI