Re: Difficult geometry problem -- tentative resolution

Hi Joseph,

you have logical errors in your geometry.
Find attached the modified input file correcting these problems.
Please next time before submitting a geometry problem try to debug it
properly.

V.

On 06/14/10 18:56, Fasso, Alberto wrote:
> Hi Joe,
>
> I am forwarding also this mail to the fluka-discuss list.
>
>
>> It appears to me that Fluka does not like regions defined with a World
>> volume (first layer inside the blackhole) and infinite planes. I
>> suggest this is a program bug, but maybe there is a caveat somewhere.
>> I found I could get around the problem by defining finite regions inside
>> World.
>>
> I don't know what you mean by "a World volume": there is no such expression in Fluka's geometry jargon. If you mean that you cannot define an external
> blackhole using open bodies such as infinite cylinders and planes, you are right:
> the manual indeed says:
> "The external blackhole must be completely surrounded by the boundary of a closed
> body, and therefore cannot be defined by means of half-spaces or infinite cylinders only".
> But in the input you have attached, "World" is a region inside the external blackhole
> region "BlckHole", and therefore there should not be any constraint in defining it
> by means of planes. I hope somebody will find the time to analyze your input to find
> the error.
> I am sorry, but I must insist on deprecating the use of ARBs that you seem to like so
> much. Maybe they are not the cause of your present problem, but they can become
> the cause of other problems. You seem to ignore that you can define a region as a collection
> of pieces, separate or partially overlapping, by means of the OR operator ( | operator
> in free format). An ARB is easily replaced by a combination of RPPs cut by
> planes.
>
> > From your previous mail:
>
>
>> With regards to the other issues of the Fluka geometry, first I want to
>> submit a very strong vote against removing the extra bodies. Leave the
>> warning comments, but also leave (or improve) the features. This is the
>> first time I used them, I tried to avoid them, but decided they were
>> necessary to the case. An RPP, for example, only has edges parallel to
>> coordinate axes, while I am dealing with rotated structures. Adding a
>> rotated RPP (e.g., RPR) would be helpful, but some of my cases need the
>> flexibility of ARB. In my opinion, Fluka already has too few body
>> shapes.
>>
> The next FLUKA version will allow you to rotate RPPs (and to expand/shrink them).
> The lack of flexibility is only apparent:: it is clear that you are looking
> for regions that can be described by simple + and - operations. This is why you find
> that Fluka has too few body shapes. But using OR you can easily build more complex
> shapes using the existing bodies.
> However, another feature of the next version is that the user can define any
> shape which can be described by a second degree equation. These can be closed
> bodies (e.g. ellipsoids) but mainly open bodies (paraboloids, hyperboloids,
> ...)
> Of course these are not the shapes you have in mind, but as I said, those
> shapes can be easily built by combining the available ones (perhaps rotated
> and expanded/shrunk).
>
>
>> I am looking forward to the time that an XML approach can be used for
>> Fluka. GDML works pretty well for Geant4; I had some students once who
>> designed something similar to and even better than GDML at the time, and
>> it was fabulous. The internal philosophies of Geant and Fluka are very
>> different, and that is entirely good for me. No debate here. But I
>> fear that Fluka is falling more and more out of the trends of how
>> programs interface with people.
>>
> We know by experience that people coming from experience with Geant or similar
> programs often find the FLUKA geometry unfriendly. But I can assure you that the
> opposite is also true: users who have started with Combinatorial Geometry find
> the Geant geometry difficult to use (you are probably surprised!)
> Our preference for Combinatorial Geometry has deep reasons that it would be
> long to argue about here in detail: in short, CG is far more accurate and is based on a concept
> of sharp boundaries between regions (rather than "volumes" floating in a poorly defined
> "mother volume") that allows importance biasing, fluence scoring at boundaries, precision
> dosimetry at material interfaces and especially optimized transport of charged particles.
> It looks to us that these advantages are much more important than friendly
> user interfaces.
> However, Vasilis Vlachoudis has developed a new technique (to be included soon in Flair)
> that should make much easier the construction of a user geometry.
>
> Kind regards,
>
> Alberto
>
> ________________________________________
> From: Joseph Comfort [Joseph.Comfort_at_asu.edu]
> Sent: Sunday, June 13, 2010 5:25 PM
> To: Fasso, Alberto
> Subject: Re: Difficult geometry problem -- tentative resolution
>
> It appears to me that Fluka does not like regions defined with a World
> volume (first layer inside the blackhole) and infinite planes. I
> suggest this is a program bug, but maybe there is a caveat somewhere.
>
> I found I could get around the problem by defining finite regions inside
> World. Attached is a start on reconstructing my geometry, for part of
> the first portion of the beamline. (More stuff is needed.) A picture
> from flair is also attached. All output files are quite normal.
>
> There are NO reported geometry or runtime errors so far with limited
> testing. Note that the input file includes several ARBs, and some ARBs
> inside ARBs. High-precision input has not been used. Maybe some errors
> will show up later. I will eventually run millions of events. I am
> including several pseudo-detectors along the beamline (the horizontal
> axis at 0) to check profiles for peculiar behaviors.
>
> I think people were misled by the unusual use of some bodies. There is
> no proof yet that they were the source of the problems. Rather, it was
> the (too-)simple (?) use of an infinite plane that led to failures. At
> least, so far, so good.
>
> Joe Comfort

-- 
-------------------------------------------------------
Vasilis Vlachoudis
Dep. EN-STI-EET
Web: home.cern.ch/bnv
Tel: +41-22-7679851
Fax: +41-22-7669644
-------------------------------------------------------