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
Re: None Re: Materials for G4OpticalPhoton simulation (Makoto Asai)
Date: 09 Aug, 2017
From: <herr_apa>

Hi Makoto,

Thanks for the quick reply! Your answers to 3) and 4) go a long way towards solving my problems. For 1) and 2), it seems I've oversimplified the description of my geometry for the sake of making the question more concise. The geometry isn't really a voxelization, and I don't implement it using a parameterized volume. It's a mesh of tessellated solids generated from a CAD model. I've got a big world box, and in that box I place a large number (millions, maybe more in the future) of G4TessellatedSolids. They are all direct daughters of the world. Each cell has a different shape, so each cell gets its own solid and logical volume. In the end, the number of logical volumes equals the number of cells - The only way not to spend time in G4ProductionCutsTable::ScanAndSetCouple is to reduce the number of G4Materials.

The simplest way to think of the geometry is probably as a tunnel filled with an absorbing/scattering medium. The shape of the tunnel wall is nontrivial, and the properties of the medium changes rapidly along the tunnel. The tunnel wall is not a problem because all of its cells can use the same material. But in the absorbing/scattering medium, each cell needs to have its own G4MaterialPropertiesTable.

5) Can I give the cells in my medium unique G4MaterialPropertiesTables without also giving them unique G4Materials? Technically I guess I could build a data structure to store all the geometry info myself, wrap it in a parameterized volume and assign PropertiesTables in ComputeMaterial. But that feels a bit unnatural (the motivation for parameterized volumes is less memory consumption, which doesn't apply here) and messy from a design perspective.

For the sake of completion, I should add that reflection is assumed to take place only on the wall-medium boundary. All the medium cells are assigned the same refractive index. It's the absorption and scattering properties that change.

When it comes down to it, I can probably afford giving each cell a unique material memory-wise. The real problem is the time spent in ScanAndSetCouple. I don't have a full understanding of the initialization procedure, but it feels like an easy solution could be to let the user opt out of calling G4ProductionCutsTable::UpdateCoupleTable.

6) Would there be any consequences of skipping UpdateCoupleTable in a simulation where no physical process creates new particles? It is feasible to add an opt-out functionality?

// Anders

 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 ]