Message: Re: Porous Material : any Idea Not Logged In (login)
 Next-in-Thread Next-in-Thread
 Next-in-Forum Next-in-Forum

None Re: Porous Material : any Idea 

Forum: Geometry
Re: Question Porous Material : any Idea (Guillaume Potdevin)
Re: None Re: Porous Material : any Idea (Marc Verderi)
Date: 29 Nov, 2005
From: Guillaume Potdevin <guillaume.potdevin@esrf.fr>

This is a multi-part message in MIME format.
--------------040105050903090901080003
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Marc Verderi wrote:
> *** Discussion title: Geometry
> Email replies to PublicHyperNews@slac.stanford.edu must include:
>   In-Reply-To: <438C674B.2080205@in2p3.fr>
>   Subject: ...change this to be about your reply.
>
> Guillaume Potdevin wrote:
>
>   
>> *** Discussion title: Geometry
>> Email replies to PublicHyperNews@slac.stanford.edu must include:
>>  In-Reply-To: <"/geometry/472"@geant4-hn.slac.stanford.edu>
>>  Subject: ...change this to be about your reply.
>>
>> Dear Geant4 users
>>
>> I have successfully used Geant4 for a number of simulations and now I
>> would like to go one step ahead:
>>
>> I would like to be able to study porous materials, and more precisely
>> powders. I know the code is certainly not made to handle with several
>> objects of various shapes; but it would be already interesting to have a
>> stack of radomly placed cubes for example...
>>
>> The problem is that I cannot use a kind of "random drop technique" for I
>> am sure I will have problems of overlapping of objects.
>>
>> So does anybody have an idea to define such a geometry, even if I am to
>> take 95% of the available gig of memory, and if simulations will last
>> for days and days?
>>
>> Thanks in advance for your suggestions.
>>
>>  
>>
>>     
> (If the parallel geometry capability would be available today, there 
> would probably be easier solution than what is below (*)).
>
> This does not look an easy problem and will probably be time consuming 
> (especially if the number if volumes is large, of course).
>
> About the overlaping question, I know that the G4VSolid class defines a 
> "CalculateExtent" method which could be used, but this looks to require 
> some expertise.
>
> Maybe with spheres it could be less difficult ? That is assuming the 
> powder is made of spheres of diameter R. It could be done something like 
> shooting random (x,y,z) points and for each new point take care if this 
> new point is at least at a distance > 2*R of any other sphere (and to 
> avoid taking "sqrt" many times, check first if |x-x_new_point| > 2*R, if 
> so accept the point, and if not check for y then z difference and only 
> in the case the 3 previous tests failed, check the distance between the 
> 2 points. If this distance is < 2*R, reject the point). At some point, 
> the fraction of rejected points might reach some asymptot.
>
> Maybe a better way would be to apply above algorithm to some small 
> space, say 5.R * 5.R * 5.R. And, in this small space, shoot points about 
> the center in [-3R, +3R] ranges in each direction (3.R instead of 5.R/2 
> = 2.5R to avoid depletion on the region boundary). Then move to the next 
> region space, 10.R further in some direction. When filling this new 
> space, only the neighbours of this region need to be tested, instead of 
> the all volume. Of course, this requires somewhat management...
>
> Not sure this helps...
>
> Cheers,
> Marc
>
> (*): with parallel geometry capability, the problem could be solved as : 
> particles are traced in an empty volume, but at the begining of the 
> step, decide, randomly, at what distance will be the next powder grain, 
> then limit the step to this distance and switch the tracking to a 
> geometry containing only a powder grain. Let the interaction(s) occur 
> and put back the primary and any secondaries in the first geometry. 
> etc... Of course you would loose the exact grain placements, but I guess 
> this is not relevant...
>
>   
Thanks!

Indeed, so far I used a technique like the one you first described, and 
it worked so far. Of course, one can always complicate the conditions of 
non-overlapping, to describe the new object, but this has its limit, and 
one ends up with difficult-to-define algorithms to define this way the 
geometry.

I did not know about the CalculateExtent method in G4VSolid, and i will 
have a look at it (but I am far from a c++ guru).

But for sure the idea of the parallel geometry is the most interesting 
one! The exact grain placement does not matter at all of course, and I 
even use a random number generator to place my objects.
I am just wondering how to determine if the particle exits the particle 
layer or not. Maybe this could be done by adding all the displacement in 
one direction (considering we have a layer of powder).
BTW, maybe it is possible to implement this in the code like it is now, 
no? I will try to have a look, but I am afraid it is too much for my 
programming skills (like I learned to program with Geant...)

Thanks a lot!

Guillaume.

-- 
*Guillaume Potdevin*
/Instruments Support Group, Special Detectors/
/European Synchrotron Radiation Facility (ESRF)
6 rue Jules Horowitz, B.P.220
38043 Grenoble Cedex
France/
*Tel: +33.(0)4.76.88.28.13 Fax: +33.(0)4.76.88.25.42 *
Web : http://www.esrf.fr/Phonebook/StaffWebPages/gpotdevi/

--------------040105050903090901080003
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Marc Verderi wrote:
<blockquote cite="mid438C674B.2080205@in2p3.fr" type="cite">
  <pre wrap="">*** Discussion title: Geometry
Email replies to <a class="moz-txt-link-abbreviated"
 href="mailto:PublicHyperNews@slac.stanford.edu">PublicHyperNews@slac.stanford.edu</a> must include:
  In-Reply-To: <a class="moz-txt-link-rfc2396E"
 href="mailto:438C674B.2080205@in2p3.fr">&lt;438C674B.2080205@in2p3.fr&gt;</a>
  Subject: ...change this to be about your reply.

Guillaume Potdevin wrote:

  </pre>
  <blockquote type="cite">
    <pre wrap="">*** Discussion title: Geometry
Email replies to <a class="moz-txt-link-abbreviated"
 href="mailto:PublicHyperNews@slac.stanford.edu">PublicHyperNews@slac.stanford.edu</a> must include:
 In-Reply-To: &lt;"/geometry/472"@geant4-hn.slac.stanford.edu&gt;
 Subject: ...change this to be about your reply.

Dear Geant4 users

I have successfully used Geant4 for a number of simulations and now I
would like to go one step ahead:

I would like to be able to study porous materials, and more precisely
powders. I know the code is certainly not made to handle with several
objects of various shapes; but it would be already interesting to have a
stack of radomly placed cubes for example...

The problem is that I cannot use a kind of "random drop technique" for I
am sure I will have problems of overlapping of objects.

So does anybody have an idea to define such a geometry, even if I am to
take 95% of the available gig of memory, and if simulations will last
for days and days?

Thanks in advance for your suggestions.

 

    </pre>
  </blockquote>
  <pre wrap=""><!---->(If the parallel geometry capability would be available today, there 
would probably be easier solution than what is below (*)).

This does not look an easy problem and will probably be time consuming 
(especially if the number if volumes is large, of course).

About the overlaping question, I know that the G4VSolid class defines a 
"CalculateExtent" method which could be used, but this looks to require 
some expertise.

Maybe with spheres it could be less difficult ? That is assuming the 
powder is made of spheres of diameter R. It could be done something like 
shooting random (x,y,z) points and for each new point take care if this 
new point is at least at a distance &gt; 2*R of any other sphere (and to 
avoid taking "sqrt" many times, check first if |x-x_new_point| &gt; 2*R, if 
so accept the point, and if not check for y then z difference and only 
in the case the 3 previous tests failed, check the distance between the 
2 points. If this distance is &lt; 2*R, reject the point). At some point, 
the fraction of rejected points might reach some asymptot.

Maybe a better way would be to apply above algorithm to some small 
space, say 5.R * 5.R * 5.R. And, in this small space, shoot points about 
the center in [-3R, +3R] ranges in each direction (3.R instead of 5.R/2 
= 2.5R to avoid depletion on the region boundary). Then move to the next 
region space, 10.R further in some direction. When filling this new 
space, only the neighbours of this region need to be tested, instead of 
the all volume. Of course, this requires somewhat management...

Not sure this helps...

Cheers,
Marc

(*): with parallel geometry capability, the problem could be solved as : 
particles are traced in an empty volume, but at the begining of the 
step, decide, randomly, at what distance will be the next powder grain, 
then limit the step to this distance and switch the tracking to a 
geometry containing only a powder grain. Let the interaction(s) occur 
and put back the primary and any secondaries in the first geometry. 
etc... Of course you would loose the exact grain placements, but I guess 
this is not relevant...

  </pre>
</blockquote>
Thanks!<br>
<br>
Indeed, so far I used a technique like the one you first described, and
it worked so far. Of course, one can always complicate the conditions
of non-overlapping, to describe the new object, but this has its limit,
and one ends up with difficult-to-define algorithms to define this way
the geometry.<br>
<br>
I did not know about the CalculateExtent method in G4VSolid, and i will
have a look at it (but I am far from a c++ guru).<br>
<br>
But for sure the idea of the parallel geometry is the most interesting
one! The exact grain placement does not matter at all of course, and I
even use a random number generator to place my objects. <br>
I am just wondering how to determine if the particle exits the particle
layer or not. Maybe this could be done by adding all the displacement
in one direction (considering we have a layer of powder).<br>
BTW, maybe it is possible to implement this in the code like it is now,
no? I will try to have a look, but I am afraid it is too much for my
programming skills (like I learned to program with Geant...)<br>
<br>
Thanks a lot!<br>
<br>
Guillaume.<br>
<br>
<div class="moz-signature">-- <br>
<div class="moz-signature"><small><b><font color="#009900">Guillaume
Potdevin</font></b></small><br>
<font color="#993300"><small><i>Instruments Support Group, Special
Detectors</i><br>
<i>European Synchrotron Radiation Facility (ESRF)<br>
6 rue Jules Horowitz, B.P.220<br>
38043 Grenoble Cedex<br>
France</i></small></font><small><small><br>
</small><b><font color="#6666cc">Tel: +33.(0)4.76.88.28.13 Fax:
+33.(0)4.76.88.25.42 </font></b></small><br>
<font color="#993399"><small>Web : <a class="moz-txt-link-abbreviated"
 href="http://www.esrf.fr/Phonebook/StaffWebPages/gpotdevi/">http://www.esrf.fr/Phonebook/StaffWebPages/gpotdevi/</a></small></font>
</div>
</div>
</body>
</html>

--------------040105050903090901080003--

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

 Add Message Add Message
to: "Re: Porous Material : any Idea"

 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 ]