RE: Difficult geometry problem

Hi Joe,

please keep the discussion on the fluka-discuss list, and don't send your
comments to me alone.
Other people can contribute better than I, and if something useful turns up,
it is good that all users
can profit of it.

I am forwarding to the list this mail and another one that I just got from you.
I will answer if I can

Alberto
________________________________________
From: Joseph Comfort [Joseph.Comfort_at_asu.edu]
Sent: Saturday, June 12, 2010 10:02 AM
To: Fasso, Alberto
Subject: Re: Difficult geometry problem

Hi Alberto,

Since writing last, I have tried to trace back where the problems begin
by stripping out most everything and trying to rebuild from the
beginning. I now have a very simple input file with no ARBs, BOXs, etc.
-- indeed almost nothing except a blackhole, air region, and vacuum
region. It fails. The .inp, .out, .err, and .log files are attached.
(I was incorrect in saying earlier that the .err and .log files showed
only normal output. I was looking at the wrong files.)

The file also has a 'target' region. The BEAM and BEAMPOS cards here
are replacements for a SOURCE card to read data from a prior
target-production stage. The output file of that stage has particles at
about 14.5 cm from the origin, passing through air. It is a little
unclear to me whether Fluka will work if particles are started inside a
material, so I added a small vacuum 'target' region. The input file
fails with or without this region.

I have not yet found a way around this prime failure. I have some ideas
based on an earlier and very successful beamline simulation. The
configuration in that case was considerably simpler and could be handled
without use of the 'forbidden' bodies. Now we need more precise
results. Until the prime failure is solved, I can not conclude that the
extra body shapes are an issue of concern.

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. Generating input files with all of the logic for defining
regions and subtracting them from other regions is very tedious and
leads to many geometry errors that have to be worked through. Having to
use 6 infinite planes per ARB, with accurate specifications of the
perpendicular vectors, will make the input file pretty near unreadable
by people, and prone to even more errors of construction.

While I can appreciate the precision needs of a program, and certainly
appreciate the double-precision nature of Fluka, I am looking at things
from the viewpoint of a user. We do not know our world to 14
significant digits (sd). If a person can extend his/her 3-sd number to
14 sd, a computer program can do it better and the user should not have
to write one. If infinite planes work better inside Fluka, the code can
translate an ARB into 6 planes with all of the precision it needs,
saving a huge effort on the part of a user. If perpendicularity is good
to some level (perhaps a user parameter), the code can extend it to full
precision.

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.

I look forward to the new release with the #include option, and wish I
had it now. I like your suggestion of the LATTIC option, particularly
in putting the prototype in the blackhole. I had considered LATTIC at
one time, but was not clear about something. In addition to the
prototype, don't I also have to define at least the outline of each
extra region in detail? That seemed awkward in my case, with the
various angles. Maybe some large RCC will work.

Again, thank you for your comments. I will continue to work to find a
solution.

Best regards,
Joe
Received on Mon Jun 14 2010 - 23:35:11 CEST