Add a modified version of the Generic Cal Endcap with conical cutout

[tmadlener]

BEGINRELEASENOTES

• Add a modified version of the Generic Calorimeter Endcap with conical cutout

ENDRELEASENOTES

Bringing more things back from the muon collider fork. @madbaron @bartosik-hep FYI

[andresailer]

This is not without a cutout, but with a conical cutout?

Can't we add this as an alternative option to the other driver instead?

[bartosik-hep]

@andresailer From the driver point of view - yes, it's easy to include the 2nd radius of the cutout as an extra parameter, which falls back to the same radius if not defined.
The problem is that we already have a frozen geometry that uses o2_v01 driver in it, so if we change the driver version it will make our compact detector description incompatible with older releases.

[andresailer]

The problem is that we already have a frozen geometry that uses o2_v01 driver in it, so if we change the driver version it will make our compact detector description incompatible with older releases.

Can you elaborate on your package structure? Where do your XML files and drivers live for the moment? Do you have them in your own fork of k4geo, or some other package?

[bartosik-hep]

The XML files of the frozen geometry I mentioned are currently collected here, and it uses all the standard drivers except for the one added in this PR.

[andresailer]

And how do you install that package along with a newer k4geo package? Because that is what you would need to do if you need backward compatibility? Or do you just copy the XML folders?

[tmadlener]

I think the main idea was to do the driver(s) first, because the XML files can in principle also be put somewhere else / read from somewhere else. Then the XML files would come in a separate PR to not overload this one too much.

[madbaron]

For now the xmls are just copied over manually.

As Thomas notes above, in a few months we'll make a separate PR with the frozen 3 TeV geometry (MuColl_v1) and the two 10 TeV detector concepts.

[madbaron]

Hi - would it be possible to get this one merged?
We'd like to follow up with a PR implementing the MUSIC and MAIA detector concepts, and switch the muon collider software stack to using k4geo instead of the muon collider lcgeo fork.

[tmadlener]

Picking up a few points that have been raised earlier:

Can't we add this as an alternative option to the other driver instead?

If we do this, how would the versioning work for the driver? I don't really like the idea of silently introducing a new option, but not bumping any of the version information. That would either make it a o1_v02 or o2_v01. I am not sure which bump would technically be the most appropriate in this scenario, but o2_v01 would already be in use, and in principle this is the second option for the Endcap calorimeter. Or am I missing something obvious here @andresailer?

@madbaron how far away are the MUSIC and MAIA PRs from being opened? Maybe they could just start off this branch (i.e. include these changes for the time being) and then we merge them in smaller chunks.

First step in any case is to get this to build again ;)