RE: Help-Fluka dies with core dump RC=34304 Error (Geometry data to big???)

Steve,

The fact that you are hitting array limits where most people don't (even those with complex geometries) makes me think that you may not be defining the geometry in an efficient way. Even if we were to modify that limit in some COMMON block or other array limit directive your simulation would probably run slowly.

I would suggest the following:
1- Be modular in the way you implement your geometry, for instance, if you define a quadrupole in your beamline, do not subtract each subvolume from the outside air, but rather subtract a box from the outside air, and then within that box define your logic, i.e. enclose your components in containing volumes.
2- Use the lattice/rot-defi capabilities so as to avoid defining a myriad of repetitive components
3- Define/fragment your geometry in such a way that each region is not surrounded by too many (e.g. hundreds) neighboring regions.

Mario

-----Original Message-----
From: Kramer, Stephen L [mailto:skramer_at_bnl.gov]
Sent: Tuesday, December 04, 2012 3:34 PM
To: Santana, Mario
Subject: RE: Help-Fluka dies with core dump RC=34304 Error (Geometry data to big???)

Thanks for the suggestion.
However it isn't the number of regions that is the problem.
  After reading the bodies FLUKA prints out an number for the FPD array. That number has exceeded 1005 and that maybe indication of the problem. I have tried backing out some bodies and the FPD to 943 and still crashes with a core dump.
Also cut back to 776 and still crashes.
One of the last runs of a smaller number of bodies had FPD 744 and that ran okay but slow and its err file says it has GEOMETRY SEARCH ARRAY FULL This is really puzzling me and I can't make any progress for now.
Wonder why my questions to the discussion Group aren't making it to the website?
Thanks for the help but if you have any idea about the FDP array data let me know.
Steve

-----Original Message-----
From: Santana, Mario [mailto:msantana_at_slac.stanford.edu]
Sent: Monday, December 03, 2012 5:34 PM
To: Kramer, Stephen L
Subject: Re: Help-Fluka dies with core dump RC=34304 Error (Geometry data to big???)

Hi Steve,

How many regions has your geometry? If it is more than 1000 you should so say in a GLOBAL card, first WHAT (http://www.fluka.org/fluka.php?id=man_onl&sub=40)

Hope this helps,

Mario

On Dec 3, 2012, at 11:23 AM, Kramer, Stephen L wrote:

Hi Mario,
I see you are actively involved in the FLUKA discussion Group. They don't seem to make it onto the Discussion Group website.
I haven't been able to get a response to my first issue when I was getting a GEOMETRY SEARCH ARRAY FULL error on the .err file. See below

Now I am since I added more regions and bodies I get a Crash of FLUKA.
Are there larger array version of FLUKA available? I am trying to model the Booster tunnel and shield wall for NSLS-II.
The previous people that specified the local shielding really screwed up and I have been asked to find and shield the possible loss points for all the accelerators and the Booster at 3 GeV extraction is the biggest problem.
Thanks for any help you can give on this since it's the critical issue and I am stuck now. Fluka worked quite well on the Linac but it was much smaller problem. I also have comparisons with measurements of the radiation dose they measured for the incident and will try to publish when I get the chance.
BTW I was using FLUKA to track the Cerenkov photons in my Beam Loss monitors before the incident that has pulled me 150% of the time.
Best Regards Steve

   *** dp/dx:d,imat,ztar,ij,po,eo -5.35021666E-05 29 2.9900636 51 3.48031313
   4.1633337 ***
   *** x,xoster,ccster,d0ster 0.182751123 0.1827 -3.2367 0. ***
   *** dp/dx:d,imat,ztar,ij,po,eo -5.35021666E-05 29 2.9900636 57 3.48031313
   4.1633337 ***
   *** x,xoster,ccster,d0ster 0.182751123 0.1827 -3.2367 0. ***
1NUMBER OF BEAM NUMBER OF BEAM APPROXIMATE NUMBER AVERAGE TIME USED TIME LEFT (RESERVED NUMBER OF STARS
PARTICLES HANDLED PARTICLES LEFT OF BEAM PARTICLES BY A BEAM PARTICLE 10000.0 SECONDS CREATED
                                             THAT CAN STILL BE FOR PRINTOUT)
                                             HANDLED

NEXT SEEDS: 0 0 0 0 0 0 98F3 3039 0 0
           1 999 999 5.0018311E-02 1.0000000E+30 0
  NEXT SEEDS: FB69 0 0 0 0 0 98F3 3039 0 0
          20 980 980 1.0678406E-01 1.0000000E+30 4
  NEXT SEEDS: 247CAE 0 0 0 0 0 98F3 3039 0 0
                                         ****************************************
                                                GEOMETRY SEARCH ARRAY FULL
                                         ****************************************
          40 960 960 1.0758438E-01 1.0000000E+30 42
  NEXT SEEDS: 4A723D 0 0 0 0 0 98F3 3039 0 0
          60 940 940 1.1289978E-01 1.0000000E+30 96
  NEXT SEEDS: 75078F 0 0 0 0 0 98F3 3039 0 0
From: Kramer, Stephen L
Sent: Saturday, December 01, 2012 12:19 PM
To: 'fluka-discuss_at_fluka.org<mailto:fluka-discuss_at_fluka.org>'
Cc: 'Vasilis Vlachoudis'; 'afasso_at_jlab.org<mailto:afasso_at_jlab.org>'
Subject: Help-Fluka dies with core dump RC=34304 Error (Geometry data to big???)

Seems like I hit some sort of limit in FLUKA Earlier I was getting GEOMETRY SEARCH ARRAY FULL error But I have added significant number of new regions and now I am getting just a core dump after the geometry is read in. No error file is generated.
I tried gdb to debug but it doesn't seem to find error other than generic signal 6 generated.
Is there a version of FLUKA that has larger arrays for the geometry?

Vasilis the newer version seems to fix the GNU plot Log(0) problem. Thanks Do you have a new e-mail address for Roberto Versaci? Or anyone else who was looking for a job using FLUKA?
I am pushing to setup a Radiation Physics group here at BNL and FLUKA will be a key calculation tool.
Thanks Steve

Stephen L. Kramer , PhD
Accelerator Physicist
Photon Science Accelerator Division
Brookhaven National Lab.
Bldg. 817m, Rm 74
Upton, NY 11973
631-344-4925
631-344-3395 (fax)
631-356-4192 (cell)

<Screenshot-Geometry Debug-1.png><BoosterExtDCSeptShdB1B2ArcShdQFBDBFSS1_VC001.out><BoostExtDCSeptShdPolyB1B2_ArcShdQFBDBF3SS1_VC.flair><BoosterExtDCSeptShdB1B2ArcShdQFBDBFSS1_VC.inp><BoosterExtDCSeptShdB1B2ArcShdQFBDBFSS1_VC001.log><fort.16>
Received on Wed Dec 05 2012 - 09:31:13 CET