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

Hi Tomek and Mike:

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.

> 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. :(

> Shuang, without more information, it is difficult to determine what the
> problem is. Does this only happen with this one setup? What modules are
> you using? are there any changes you've made to the source (besides your
> problem setup)?

Sorry about that. It never happened to me except this setup. However,
even for this setup, lower resolution (less AMR levels) works fine.

Also note this run has the biggest meshes I've ever used. These are
the modules:
*****************************************************
#Modules file for rm_3d generated by setup -auto

INCLUDE database/amr/paramesh2.0
INCLUDE driver/time_dep
INCLUDE hydro/explicit/split/ppm/diffuse
INCLUDE io/amr/chombo
INCLUDE materials/conductivity/constant
INCLUDE materials/eos/gamma
INCLUDE materials/mass_diffusivity/constant
INCLUDE materials/viscosity/constant
INCLUDE mesh/amr/paramesh2.0/second_order_old
INCLUDE util/tools
INCLUDE util/wrapping
******************************************************

I didn't modify any kernel part of FLASH except the problem
setup, mainly init_block.F90.

Best wishes

-shuang

-----Original Message-----
From: Tomasz Plewa [mailto:tomek@flash.uchicago.edu]
Sent: Monday, April 28, 2003 8:20 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 -

Can you try dbx instead of gdb?

Tomek

--
On Mon, Apr 28, 2003 at 06:46:04PM -0500, Mike Zingale wrote:
> Shuang, without more information, it is difficult to determine what the
> problem is.  Does this only happen with this one setup?  What modules are
> you using? are there any changes you've made to the source (besides your
> problem setup)?
>
> 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
>
>
>
>
> On Mon, 28 Apr 2003, Shuang Zhang wrote:
>
> > Hi Mike:
> >
> > Thanks for your quick hint. However, when I type in
> >
> > "gdb -c core", it gives me:
> >
> > "/teal/caip3/zhang/FLASH2.1/setups/rm_3d/core" is not a
> > core dump: File format not recognized
> >
> > Although it says in stderr there is a core dumped. Any
> > suggestions? As a reminder, our machine has a LSF queueing
> > system and "uname" gives:
> >
> > SunOS teal.rutgers.edu 5.7 Generic_106541-23 sun4u sparc SUNW,
> > Ultra-Enterprise-10000
> >
> > Best
> >
> > -shuang
> >
> > -----Original Message-----
> > From: owner-flash-users@flash.uchicago.edu
> > [mailto:owner-flash-users@flash.uchicago.edu]On Behalf Of Mike Zingale
> > Sent: Friday, April 25, 2003 5:20 PM
> > To: Shuang Zhang
> > Cc: flash-users@flash.uchicago.edu
> > Subject: Re: [FLASH-USERS] FW: 3D RM Problem
> >
> >
> > Shuang, according to your stderr log, you are getting a core dump from
one
> > of the processors -- have you tried looking at a stack trace from the
core
> > file to see where it is crashing?  It is not clear what the problem is
> > from the files you've attached, but it is possible that some error
> > messages are buffered and not being properly written out when that
> > processor crashes.
> >
> > Mike
> >
> >
> >
> > On Fri, 25 Apr 2003, Shuang Zhang wrote:
> >
> > > Hi:
> > >
> > > My 3D Richtmyer-Meshkov simulation stopped with no error symptom
> > > in the log and output files. I doubt it is a memory overflow
> > > on the SUN E10K (32CPU, 16GB RAM). But according to my
> > > previous experience there should be a notice in the log files.
> > >
> > > The same thing happened on a 72GB RAM SUN system.
> > >
> > > The early data dumpped out looks fine.
> > >
> > > Attached the init, output and log files. Any clue?
> > >
> > > Thanks much for your attention and help.
> > >
> > > -Shuang Zhang
> > > Vizlab, Rutgers University
> >
--