experimental ILD models for FCCee

[danieljeans]

BEGINRELEASENOTES

• Fix severe overlaps in ILD_l5_v11 inner tracker (outer barrel layer)
• Introduce new experimental models ILD_FCCee_v01 and ILD_FCCee_v02 under FCCee/ILD_FCCee directory
  -- MDI from FCCee common MDI area
  -- vertex & lumi cal identical to CLD_o2_v07
  -- for ILD_FCCee_v01: inner tracker now based on TrackerBarrel_o1_v06 (adapted from CLD_o2_v07), TPC inner radius slightly increased 329 -> 365 mm to avoid MDI envelope
  -- for ILD_FCCee_v02: inner tracker identical to CLD_o2_v07, TPC inner radius significantly increased 329 -> 701 mm to accommodate larger inner tracker
  -- no ECAL ring, LHCAL, beamcal
  -- other subdetectors same as ILD_l5_v02
  -- some moving/renaming of definitions in ILD_common_v02 was necessary
  ENDRELEASENOTES

[danieljeans]

@Victor-Schwan was heavily involved

[Zehvogel]

You probably want to pick up also this LumiCal change: #391

Have you considered putting the ILD FCCee model into the FCCee directory? This might make its existence a bit more obvious :)

[danieljeans]

@Zehvogel I had the same thought, we'll discuss it in ILD; maybe at least link it to the FCC directory.

[tmadlener]

Looks like merging #388 introduced a conflict here (as far as I can see, it should be straight forward to fix by dropping the first commit).

Did you also start to check whether this can be put into the FCCee/ILD_FCCee (or similar) either fully living there or via some clever symlinking?

[danieljeans]

• fixed the conflicts (some missing definition...)
• moved the ILD_FCCee_v01 model to the FCCee directory. Sym-linking is non-trivial because main description files live at different depths under FCCee/ and ILD/ , which seems to create problems with relative paths...

[tmadlener]

Sym-linking is non-trivial because main description files live at different depths under FCCee/ and ILD/ , which seems to create problems with relative paths...

Yeah, this is what I was expecting. I think symlinking the ILD_common_v02 to FCCee/ILD_FCCee is probably the best we can do, unless we want to explicitly copy the contents over.

[danieljeans]

still to do: fix materials definitions in
ILD/compact/ILD_common_v02/materials.xml

which give rise to warnings:

Warning in <TGeoMixture::ComputeDerivedQuantities>: Mixture RPCGAS2: sum of weights is: 0.99249
Warning in <TGeoMixture::ComputeDerivedQuantities>: Mixture PEEK-GF30: sum of weights is: 1.03333
Warning in <TGeoMixture::ComputeDerivedQuantities>: Mixture g10-RPC: sum of weights is: 1.10025

have contacted expert (Gerald Grenier)

[tmadlener]

Since nothing in this PR changes the materials definitions, those are pre-existing, right? In that case, I would prefer to fix that in a separate PR.

[danieljeans]

Since nothing in this PR changes the materials definitions, those are pre-existing, right? In that case, I would prefer to fix that in a separate PR.

OK, seems a good plan

[tmadlener]

Minor request from my side: Could the contents of the README.mds that are currently in the v01 and v02 folders be put into one top level README.md in the compact top level folder? I think that would make it easier to see what the different models represent on a quick glance.

[tmadlener]

I am not sure I fully understand why the vis attributes need to be renamed, resp. where the collision is coming from. Shouldn't that just be an issue in case a vis property that is used by any detector is not defined? What am I missing here?

[Victor-Schwan]

I am not sure I fully understand why the vis attributes need to be renamed, resp. where the collision is coming from. Shouldn't that just be an issue in case a vis property that is used by any detector is not defined? What am I missing here?

We linked subdetectors from CLD. In the XML file of the CLD Inner Tracker RedVis is defined (see https://github.com/key4hep/k4geo/blob/main/FCCee%2FCLD%2Fcompact%2FCLD_o2_v07%2FInnerTracker_o2_v08.xml#L70) which causes a conflict with the definition in ILD_common_v02. Hence, we decided to rename ILDs vis attributes.

[tmadlener]

We linked subdetectors from CLD. In the XML file of the CLD Inner Tracker RedVis is defined (see https://github.com/key4hep/k4geo/blob/main/FCCee%2FCLD%2Fcompact%2FCLD_o2_v07%2FInnerTracker_o2_v08.xml#L70) which causes a conflict with the definition in ILD_common_v02. Hence, we decided to rename ILDs vis attributes.

I see, that makes sense. Thanks. I suppose there is no easy way of leaving the other models untouched, e.g. by copying the display.xml to an ILD_FCCee_common folder, and removing the clashes? Would that not work because then the ILD parts would be missing some of the vis attibutes?

[danieljeans]

I see, that makes sense. Thanks. I suppose there is no easy way of leaving the other models untouched, e.g. by copying the display.xml to an ILD_FCCee_common folder, and removing the clashes? Would that not work because then the ILD parts would be missing some of the vis attibutes?

There is certainly scope for sharing colour definitions among different k4geo models, but it would take some effort...

[tmadlener]

What is still missing to lift this out of the WIP status that it's currently in?

[Victor-Schwan]

What is still missing to lift this out of the WIP status that it's currently in?

#381 introduces changes to the MDI e.g. to the beampipe in the common_MDI v00. We rebased on top of that PR and linked several files there. Hence, we thought to merge the other PR first. I am not sure whether the changes are needed though

[danieljeans]

What is still missing to lift this out of the WIP status that it's currently in?

#381 introduces changes to the MDI e.g. to the beampipe in the common_MDI v00. We rebased on top of that PR and linked several files there. Hence, we thought to merge the other PR first. I am not sure whether the changes are needed though

@Victor-Schwan are you sure we are based on that PR? I think it works fine on the master branch (eg the lumical is taken from the CLD directory). If that MDI PR goes through, we would update to profit from improvements/changes.
In my understanding, we're ready to remove WIP here (on the understanding that they are experimental models and not an "officially blessed" version of ILD).

[Victor-Schwan]

What is still missing to lift this out of the WIP status that it's currently in?

#381 introduces changes to the MDI e.g. to the beampipe in the common_MDI v00. We rebased on top of that PR and linked several files there. Hence, we thought to merge the other PR first. I am not sure whether the changes are needed though

@Victor-Schwan are you sure we are based on that PR? I think it works fine on the master branch (eg the lumical is taken from the CLD directory). If that MDI PR goes through, we would update to profit from improvements/changes. In my understanding, we're ready to remove WIP here (on the understanding that they are experimental models and not an "officially blessed" version of ILD).

I checked again and initially, I rebased another branch with v11 on the common mdi PR. I did not see any problem with this PR. Sorry for the confusion

[tmadlener]

ready to remove WIP here (on the understanding that they are experimental models and not an "officially blessed" version of ILD)

I think it's stated quite obviously in the provided README and to really make sure we could also put it into the release notes once more. For me this seems to be good as it is, also because there will likely be some iteration still once we have reconstruction available. So, as soon as you remove the WIP I would be fine to have a last look and merge.

[danieljeans]

WIP removed

[tmadlener]

This is good to merge from my side. Paging @BrieucF and @andresailer to make sure that they are also fine with putting this under the FCC umbrella.

[BrieucF]

This is good to merge from my side. Paging @BrieucF and @andresailer to make sure that they are also fine with putting this under the FCC umbrella.

This is fine by me!