RE: [FLASH-USERS] FW: 3D RM Problem

The strange thing to me is, the exactly same setup works fine in
2D and 3D 4 AMR levels (one level less). Does this indicate anything?
Does refine/derefine criterier playing a role?

Also, what is the highest resolution among the successful 3D simulations
in the FLASH community so far, in your database?

Thanks much!

-Shuang

-----Original Message-----
From: owner-flash-users@flash.uchicago.edu
[mailto:owner-flash-users@flash.uchicago.edu]On Behalf Of Mike Zingale
Sent: Tuesday, April 29, 2003 4:20 PM
To: Shuang Zhang
Cc: Tomasz Plewa; flash-users@flash.uchicago.edu; help@caip. rutgers.
edu
Subject: RE: [FLASH-USERS] FW: 3D RM Problem

Shuang, it is not a memory overflow, but a floating point exception. Your
compiler should have a flag that enables trapping of these exceptions, and
if so, please recompile with this enabled, so we can hopefully get a line
number of where this is occuring.

Mike

----------------------------------------------------------------------------

--
Michael Zingale
UCO/Lick Observatory
UCSC
Santa Cruz, CA 95064
phone:  (831) 459-5246
fax:    (831) 459-5265
e-mail: zingale@ucolick.org
web:    http://www.ucolick.org/~zingale
``What an awful dream -- ones and zeros everywhere.  I thought I saw a two''
   -- Bender
On Tue, 29 Apr 2003, Shuang Zhang wrote:
> Thanks Tomek!
>
> Unfortunately, we still haven't got Prism
> working for MPI debugging on our system.
>
> Here is what "dbx rm_3d core" gives:
>
> ************************************************
> detected a multithreaded program
> t@1 (l@1) terminated by signal FPE (invalid floating point operation)
> 0x00059dd4: hydro_1d+0x1e1c:    ld      [%sp + 0x26c], %o4
> (/opt2/SUNWspro/bin/../WS6U2/bin/sparcv9/dbx) where
> current thread: t@1
> =>[1] hydro_1d(0x151aeba0, 0x151aec28, 0x151af420, 0x151aed38, 0x151aedc0,
> 0x151aee48), at 0x59dd4
>   [2] hydro_sweep(0x2a0588, 0x3198b68, 0x3199dd8, 0x10, 0x50, 0x6), at
> 0x63994
>   [3] hydro_3d(0x54114, 0xffbef2f0, 0x65, 0x235536, 0x54, 0x23328a), at
> 0x55ae0
>   [4] evolve_(0x23381e, 0x233232, 0x54, 0x23323b, 0x0, 0x54), at 0x541bc
>   [5] MAIN_(0xaae61, 0xffbef464, 0xffbef470, 0x0, 0x0, 0x0), at 0x48b4c
>   [6] main(0x2, 0xffbef464, 0xffbef470, 0x29ec00, 0x0, 0x0), at 0x489f4
> **************************************************
>
> Dose this look like memory overflow?
>
> Thanks.
>
> -Shuang
>
>
> -----Original Message-----
> From: owner-flash-users@flash.uchicago.edu
> [mailto:owner-flash-users@flash.uchicago.edu]On Behalf Of Tomasz Plewa
> Sent: Tuesday, April 29, 2003 1:05 PM
> To: Shuang Zhang
> Cc: Mike Zingale; flash-users@flash.uchicago.edu; help@caip. rutgers.
> edu
> Subject: Re: [FLASH-USERS] FW: 3D RM Problem
>
>
> Shuang -
>
> > Thanks much! Before going into further discussion, let
> > me put the question this way: this simulation with base
> > block 2x1x1, 5 AMR levels (approximating resolution
> > 256x128x128), how much RAM will be necessary approximately?
> > "size" command doesn't seem to give the exact information.
>
> You can estimate the memory requirements by multiplying
>
> your equivalent uniform grid size (max case) times
>
> the number of variables (this is a sum of all named DBASE_VAR_NAMES
> and DBASE_NUMBER_OF_SPECIES from object/dbase_defines.fh) times
>
> 3 (approximate number of unk-sized arrays)
>
> times
>
> 8 (number of bytes per word).
>
> If you use 15 variables and if there would be no overhead coming from
> the ghost zones this gives a size ~1.5Gb. With 4 ghost zones on each
> side and blocks 8^3 this number has to be increased by a factor
> (16/8)^3 = 8 giving the final size of order of ~12 Gbytes.
>
> It is a very rough estimate and we are working on some tool which will
> be given memory usage estimate during setup stage.  I might missed
> some instances of unk copies and there might be some memory allocated
> by some of the modules you use.  In either case, you seem to be using
> a good fraction of the memory available on your system.
>
> > > Can you try dbx instead of gdb?
> >
> > You mean running it with 1 processor, and setting
> > maxblocks to a very large number, in order to use
> > dbx? I don't know how to debug MPI code with dbx. :(
>
> I am not sure that gdb can recognize Solaris core file and I am
> unaware of it ability to debug MPI programs. dbx should tell you if
> the core file has the right format, or perhaps that the file is
> incomplete. You should also check your shell environment for possible
> coredumpsize limits. Small size of your core file (< 1 Gb) may point
> in that direction.
>
> The standard MPI-capable graphical debugger on Suns is called
> Prism. You should check whether it is available on your system. I do
> not have any experience with it.
>
> Hope it is of some help to you.
>
> Best wishes -
>
> Tomek
> --
> Tue, 12:04 CDT (17:04 GMT), Apr-29-2003
>
____________________________________________________________________________
> ___
>
>    Tomasz Plewa                                      www:
> flash.uchicago.edu
>    Computational Physics and Validation Group        email:
> tomek@uchicago.edu
>    The ASCI Flash Center, The University of Chicago  phone: 773.834.3227
>    5640 South Ellis, RI 475, Chicago, IL 60637       fax:   773.834.3230
>
____________________________________________________________________________
> ___
>