search

AIDASoft / DD4hep

Detector Description Toolkit for High Energy Physics
http://dd4hep.cern.ch
GNU Lesser General Public License v3.0
50 stars 99 forks source link

Material Properties Table and Optical Surface Implementation #164

Closed whit2333 closed 6 years ago

whit2333 commented 7 years ago

Hi Everyone,

I wanted to get guidance on how to best implement hooks to define the Geant4 material properties table and also define optical surfaces. Here are a few thoughts and comments:

  1. G4MaterialPropertiesTable is associated with a G4Material and can include any number of properties (G4MaterialPropertyVector = G4PhysicsOrderedFreeVector). This means that the inputs can be rather lengthy, for example, wavelength shifter response for a spectrum of optical photon energies.

Adding material properties tables in the form of json (or yaml) files seems most reasonable but I suppose xml could work too. Thoughts?

  1. Since TGeoMedium does not map to G4MaterialPropertiesTable, it appears this needs to be created so that it can exist outside of DDG4. There are probably a few ways to do this but I thought I would ask in case anybody has already thought about this. The most straightforward way is to mirror Geant4's G4MaterialPropertiesTable.

  2. Optical surface properties, i.e., G4OpticalSurface need to be defined and associated with also need to be constructed outside of Geant4. These properties are defined through a G4MaterialPropertiesTable, and other optical parameters that do not take on numerical values.

Again, this could mirror Geant4's implementation but ideally the DDMaterialPropertiesTable would be able to generically include the non-numerical properties (e.g. the enumerated values for surface type, finish, and model see this for reference). Then in the DDG4 hook implementation, separate the G4MaterialPropertiesTable from the enumerated optical properties.

  1. The actual optical surface needs to be reimplemented outside of Geant4 (because AFAIK does not exist in TGeo). Here is where I think the DD4hep surfaces-concept may cause some confusing or be really useful. I am really not sure at the moment. Thoughts?

Either way, the optical surface implementation can emulate the Geant4 implementation which uses a border defined between two (physical) placements or the volume (logical) skin of an element. This should be straight a forward map to Geant4.

Anyway, I will do some more code reading and report back here an outline of my implementation plan. If you have any comments or suggestions I would love to hear them.

Cheers, Whit

MarkusFrankATcernch commented 7 years ago

Hi Whit,

I think generally you want to add arbitrary information to the TGeoMedium (the actual class corresponding to G4Material). Is this correct?

So far we have not yet come across this problem, but a solution for this is required. I know e.g. also from the LHCb detector description, that such a functionality is necessary.

In principle there is the possibility in TGeoMedium to attach an arbitrary object of type TObject using void TGeoMedium::SetCerenkovProperties(TObject* cerenkov); I believe that this is exactly your use-case. Is this correct? Unfortunately or for good reason (flexibility) TGeo did not specify the concrete type of such an object. Since so far there was no need, this functionality is (not yet) formalized in DD4hep and hence now effectively anybody could attach any object -- the perfect recipe for a disaster.

There are some changes upcoming in DD4hep according to the latest discussions concerning namespaces and typedefs (at least for the latter you participated). Hence, time is a bit scarce to properly develop this in the very near future. If you however would volunteer to contribute it would be highly welcome!

Cheers,

Markus

whit2333 commented 7 years ago

Hi Markus,

Thanks for the feedback.

I think generally you want to add arbitrary information to the TGeoMedium (the actual class corresponding to G4Material). Is this correct?

Sort of. It is about half of the "properties" challenge. The other half is assigning arbitrary information to an "optical surface", which does not exist in TGeo or DD4hep. I think this task of "assigning arbitrary information or properties" can be made slightly more general than the G4MaterialPropertiesTable, i.e., it can store the optical surface properties too.

I think it is better to not use the TGeoMedium since it is really an entirely separate concept, i.e., the "(physical) properties" concept which reduces to a special case of "material properties" or "optical properties". Actually I only just noticed that the G4LogicalSurface class has a member function G4TransitionRadiationSurface * GetTransitionRadiationSurface () const. I have never used TRDs but I would bet the (yet undefined) G4TransitionRadiationSurface would also have something like "TR surface properties". Anyway, I'm mostly just thinking out loud.

There are some changes upcoming in DD4hep according to the latest discussions concerning namespaces and typedefs (at least for the latter you participated). Hence, time is a bit scarce to properly develop this in the very near future. If you however would volunteer to contribute it would be highly welcome!

Indeed. These discussions are very encouraging. For my taste, I would rather the code structure and interfaces get done in a good way rather than worrying too much about breaking code and backwards compatibility. If I have to go and do some search and replaces, no problem if it is an overall improvement.

Cheers, Whit

MarkusFrankATcernch commented 7 years ago

Hi Whit,

could you please provide an informal list of requirements for such an object to be attached to the TGeoMaterial/TGeoMedium? If de'd know what is required, we could think of how to implement it....

Cheers, Markus

whit2333 commented 7 years ago

The TGeoMedium is in sufficient since the logical (optical) surface construct does not exist in TGeo.

Here is a work in progress: https://github.com/AIDASoft/DD4hep/pull/188

EDIT: I see now https://root.cern.ch/doc/master/classTGeoExtension.html this might be useful for the materials.

MarkusFrankATcernch commented 6 years ago

TGeoExtension may be an appropriate object to be used, since it can be attached to the TGeoMaterial. The materials in dd4hep are actually instances of TGeoMedium. Hence the access would be medium->GetMaterial()->GetFWExtension(). This call could then be "short-cutted" in an accessor of dd4hep::Material

At least this is a non-intrusive solution, which is good.

petricm commented 6 years ago

Please reopen if needed.