Updates the geometry tag.

Pulls the latest geometries from the cbmroot geometry repository.

Specifies the recommended defaults of subsystems in the setup files.

@e.clerkin,

please check https://cdash.gsi.de/viewTest.php?onlyfailed&buildid=262571 .

There are some missing parameter files for trd and tof. For trd this is in my opinion a naming problem, so I add @praisig. Maybe he can comment. For tof the parameters are missing.

Hi @f.uhlig and @e.clerkin I had a look and somehow the parameters for v20b of the Trd had names that differ from the standard naming scheme. I guess, during our studies we just copy pasted the name and this is the reason why we missed this. I created a merge request CbmSoft/cbmroot_parameter!32 (merged) to the parameter repository fixing this issue and also created a merge request !242 (merged) to update the parameter hash.

@praisig,

thanks for the fast action to fix the trd parameters.

@e.clerkin,

do you have tof parameters available for the new geometry?

@e.clerkin,

if you rebase you get at least the correct trd parameters.

added 2 commits

• 0c4f2b4a - 1 commit from branch computing:master
• 205b8a96 - Updates to use latest geometry tags.

Compare with previous version

@e.clerkin,

is the tof_v20a geometry the same as tof_v16e but placed at a different z-Position? If so I should be able to create the needed parameter files.

Hi Florian,

Yes the v20a geometry is the same as the v16e, just translated downstream.

@n.herrmann,

to fix the issue with the missing parameter files I simply created a link from

tof_v20a_1h.digibdf.par -> tof_v16e_1h.digibdf.par

To my understanding this should be correct since the internal structure of the geometry has not changed but only the position which is anyway taken from the TGeoManager.

Unfortunately this is not enough. During initialising CbmTofSimpClusterizer I get the following error which indicates that the class does not support the new geometry. Can this be fixed easily?

[INFO] CbmTofSimpClusterizer: No MCTrack array.
[INFO] Inspect node 0 magnet_container_0
[INFO] Inspect node 1 pipe_v16b_1e_0
[INFO] Inspect node 2 sts_v19a_0
[INFO] Inspect node 3 trd_v20b_1h_0
[INFO] Inspect node 4 tof_v20a_1h_0
[INFO] Found TOF geometry tof_v20a_1h_0
[INFO] CbmTofGeoHandler::CheckGeometryVersion: Found TOF geometry tof_v20a_1h_0, treat as Id 21a   
<I> V21a module mask 0x0fdfffff
[INFO] CbmTofSimpClusterizer::InitParameters with GeoVersion 4
[ERROR] CbmTofSimpClusterizer::InitParameters => Invalid geometry!!!4
[FATAL] Initialization of Task TOF Simple Clusterizer failed fatally

Another fact I don't understand is why the tof_v16 is treated as Id 14a

[INFO] Found TOF geometry tof_v16e_1h_0
[INFO] CbmTofGeoHandler::CheckGeometryVersion: Found TOF geometry tof_v16e_1h_0, treat as Id 14a   
[INFO]  * CbmTofCreateDigiPar * :: Init() 

If the two geometries are the same beside the z-Position both should be treated the same. Which of the two is now correct?

added 23 commits

• 205b8a96...81a4dfbc - 22 commits from branch computing:master
• fb0adab1 - Updates to use latest geometry tags.

Compare with previous version

added 24 commits

• fb0adab1...ddef2952 - 23 commits from branch computing:master
• 96b888e0 - Updates to use latest geometry tags.

Compare with previous version

added 1 commit

• 25fbcd33 - WIP: Update Geometry Tags

Compare with previous version

marked as a Work In Progress from e.clerkin/cbmroot_new@25fbcd331bb9eb749a6ac1f158435b44cb7dbd33

added 1 commit

• f2e8ad9a - WIP: Updating Geometry Tag

Compare with previous version

added 1 commit

• 17d02426 - Newly generated tof parameter files.

Compare with previous version

I am already working on that issue for quite some time but somehow either the digitization or the reconstruction doesn't work. Even with a changed CbmTofGeoHandler.

I have one more idea what to test and if this fails I am completely lost. Hope I manage to do the test today.

added 1 commit

• 1078bce3 - WIP: Updates Geometry Tags.

Compare with previous version

@p.-a.loizeau, @e.clerkin,

Ok. It is like I finally expected. If I create the geometry v20a with the filename tof_v16e_1e.geo.root and also the name of the top volume to be v16_e_1e the complete chain works. If I use the geometry v20a_1e which is properly detected as Id 14a the digitization crashes.

At least now I know that the problem is not the geometry or the bdf parameter file (is a link to the v16e one) are wrong but that the problem is somehow in the code.

@e.clerkin,

I found the issue. The problem is that the geometry tof_v20a_1e is not correct. It is a shifted v16d_1e geometry. The number of module types is wrong and there are 132 copies of module type 1 which was changed for the v16e geometries. The other v20a geometries _1h and _1m have the correct number of module types.

I would tend to remove the erroneous commit 3bb7564c1f3983233a72370527a32a8be1c86ffd completely and would ask you to create a new MR with correct root files.

@f.uhlig

The issue regarding the parameter file geometry mismatch was solved in last night builds. I generated new parameter and geometries using the tof macros.

Removing that commit will not solve the problem as it relates to the MVD, if this was the approach we would have to go back to f80ee173 which IMHO is not worth it. I would suggest that we just build and make correction going forward.

Before we submit anything though, there would seem to be still problems with passing all tests with this merge request. Do you know the meaning of or reason for

https://git.cbm.gsi.de/e.clerkin/cbmroot_new/-/jobs/20141#L296 .***Failed Required regular expression not found.Regex=[Macro finished successfully

?