Setting material properties for geant4 simulations beyond G4MaterialPropertiesTable (feature-request, for discussion)

[wdconinc]

As an interface to geant4, we are encountering some limits on setting material parameters. I'd like to use this issue as a way to discuss them in preparation of addressing them in a PR. Also, maybe I'm simply missing something :-)

Specific use case

In our simulations of calorimetry detectors, we use Birks' law in the G4EmSaturation process. The Birks' constant is an empirical material property in geant4 which is set with G4Material* m; m->GetIonisation()->SetBirksContant(value); and defined by default for only about 4 NIST database materials (and even then not to the values that we think they should be set to). So, we would like to set the Birks' constant as part of our geometry definition xml files, or through a c++ call in the geometry plugins. Note that DD4hep already correctly uses the G4EmSaturation energy deposition with the effects of Birks' law applied, and the only issue is setting the correct parameter.

Other use cases

The Birks' constant is hardly the only material constant that cannot be specified in gdml syntax (see G4GDMLReadMaterials for a list of supported ones). Only the Mean Excitation Energy (MEE) is supported out of the full list in G4IonisParamMat. Other properties are defined for elements in G4IonisParamElm.

Possible extensible approach to setting material properties

In GDML the <property> element inside a <material> element can refer to a GDML <matrix>, <constant>, or <quantity> element. One could envision extending this to:

<property name="BirksConstant"        ref="BirksConstant__0x123aff00"/>

which allows property names that are currently not supported by geant4, and therefore ignored.

If this way of setting material properties beyond those supported by geant4 is acceptable, then it could be possible to extend the logic in Geant4Converter::handleMaterial by not simply failing on each property index that is not recognized by geant4, but instead handling it directly using a table of additional properties supported by DD4hep.

It is not supported by geant4 to extend the supported keys in the G4MaterialPropertiesIndex (it uses a fixed enum for the supported keys). We might therefore have to create a dd4hep::Geant4MaterialPropertiesTable that extends the supported properties. Once we add, say, "BirksConstant" as a new key in Geant4MaterialPropertiesTable, then we can use this in calls to auto* ionization = mat->GetIonisation(); to set the ionization parameters based on the gdml input in a way that is currently not possible.

Upstreaming to geant4

Simultaneously, it would make sense to add the missing keys to support in geant4 and allow for properties to set e.g. the Birks' constant there. Using a local approach in dd4hep allows us to get support before that happens, and in older geant4 version. It should also be possible to add support in dd4hep only for new keys, not for those that already exist (and in which case the geant4 path should be preferred).

[andresailer]

It all sounds sensible to me. When you say GDML, you mean the DD4hep "compact" XML description, right?

The BirksConstant is just one number, right? So rather something like this

<property name="BirksConstant"        value="123.456"/>

cf.

DD4hep/DDCore/src/plugins/Compact2Objects.cpp

Line 510 in 2d88cf5

else if ( p.hasAttr(_U(value)) ) {

[wdconinc]

Yes, you are right, the BirksConstant is just a single number. When I wrote that above, I was still in the mindset of matrix property vectors since originally I thought that was the only thing that was available :-)

[wdconinc]

It all sounds sensible to me. When you say GDML, you mean the DD4hep "compact" XML description, right?

Yes, correct. I guess in this area they overlap in the schema.

[MarkusFrankATcernch]

For DD4hep this feature exists. See e.g. Compact2Objects.cpp line 591-540 (material conversion).
What is not properly implemented is the conversion to Geant4.
Here errors will occur. We could cast out the conversion of such "special" properties by
giving them e.g. a "special" name-prefix. In TGeo these properties are sub-classes of TNamed.
The title would be a way.

[MarkusFrankATcernch]

Wouter, are you actively working on this ?
If no - I would address it, but I do not want to interfere.

[wdconinc]

I am not actively working on it (and wouldn't for at least another week or so, as there are other items on our todo list that are higher priority).

[wdconinc]

I would be happy to test it, though!

[MarkusFrankATcernch]

Looks like I have a working approach:
See PR: #897

Further suggestions welcome!
Markus

[wdconinc]

Getting back to this and trying to digest the PR.

For the BirksConstant (not supported by a setter in geant4), I guess the next step would be to add a call right where the GetIonisation call is in Geant4Converter.

[MarkusFrankATcernch]

I only have added a way to add numbers to materials. How to use them then in a dedicated way I need the recipe....

[MarkusFrankATcernch]

@wdconinc
Do you have any idea what the units in Geant4 are for the ionization parameters:

• Birk's constant
• log(Mean excitation energy)
• Mean Energy Per Ion Pair

I have currently only something without any units....

[wdconinc]

Good question, but shouldn't those be in geant4's internal system of units?

[MarkusFrankATcernch]

@wdconinc
This would be G4 units:

• Birk's constant mm/MeV
• Mean excitation energy: MeV (without log!)
• Mean Energy Per Ion Pair: MeV

[wdconinc]

I guess in that sense we'd specify e.g.

<property name="BirksConstant"        value="123.456 * mm/MeV"/>

for https://github.com/Geant4/geant4/blob/geant4-11.0-release/source/processes/electromagnetic/utils/src/G4EmSaturation.cc#L278

[wdconinc]

• Birk's constant MeV/mm

I guess this one would be inverted.

[MarkusFrankATcernch]

Yes. This was a typo....

[MarkusFrankATcernch]

@wdconinc Can this issue be closed ?

[wdconinc]

Yes, this is now implemented.