Message: Re: Materials for G4OpticalPhoton simulation Not Logged In (login)
 Next-in-Thread Next-in-Thread
 Next-in-Forum Next-in-Forum

None Re: Materials for G4OpticalPhoton simulation 

Forum: Geometry
Re: None Materials for G4OpticalPhoton simulation
Date: 08 Aug, 2017
From: Makoto Asai <Makoto Asai>

Hi Anders,

I presume you use nested parameterization (most suggested) or usual parameterized volume (less suggested) to implement your voxel geometry. 

> 1) How do I create the materials in the most memory-efficient way? My
> present approach is to create all materials using the same base
> material, so that some information is shared. Can I do better?

You need two G4Material objects, though properties could be identical to each other except the pointer to G4MaterialPropertyTable. In the ComputeMaterial() method of your parameterized volume, you need to make sure voxels touching to each other should have different G4Material object (with different G4MaterialPropertiesTable). Please note that the boundary reflection process looks up G4Material pointers stored in the touchables of Pre-set and post-step points.

> 2) Disregarding memory efficiency, how do I create the geometry in the
> FASTEST way (in terms of user time)? Because I have so many voxels and
> so many materials, the program spends ages in
> G4ProductionCutsTable::ScanAndSetCouple during initialization. It's an
> unfortunate bottleneck seeing as production cuts are not relevant in
> this simulation.

The speed of this method is basically propotional to number of materials times number of logical volumes. If you have only two G4Material objects and just a few G4LogicalVolume objects (three if you use nested parameterization), it should be fast enough.

> 3) Can two materials use the same G4MaterialPropertiesTable?


> 4) Can two G4MaterialPropertiesTables use the same
> G4MaterialPropertyVector? It looks like a PropertiesTable assumes
> ownership of all its PropertyVectors and deletes them in the destructor,
> but unless I'm missing something, a G4Material never deletes its
> PropertiesTable. If the user is responsible for deleting
> PropertiesTables, then I could just let them leak and delete the
> PropertyVectors myself. DOes that sound reasonable?

Yes. Actually, the reason why G4Material destructor does not delete G4MaterialPropertyTable because we assume one G4MaterialPropertyTable object could be shared by more than one G4Material. 

Hope this helps,

Inline Depth:
 1 1
 All All
Outline Depth:
 1 1
 2 2
 All All
Add message: (add)

1 None: Re: Materials for G4OpticalPhoton simulation   (herr_apa - 09 Aug, 2017)
 Add Message Add Message
to: "Re: Materials for G4OpticalPhoton simulation"

 Subscribe Subscribe

This site runs SLAC HyperNews version 1.11-slac-98, derived from the original HyperNews

[ Geant 4 Home | Geant 4 HyperNews | Search | Request New Forum | Feedback ]