[FLASH-USERS] Re: [FLASH-BUGS] HDF5 crash

From: JB Gallagher <jbgallag@flash.uchicago.edu>
Date: Wed Jun 18 2003 - 19:02:05 CDT

Markus,

It appears that this may be a bug in the windtunnel problem. I am able to
reproduce the error using all combinations of hdf5 versions and i/o modules in
Flash, even the parallel-netcdf i/o module reports a corresponding library error
on this problem. Compiling 32 versus 64-bit makes no difference either. There
appears to be something wrong in the problem setup. So the good news is you can
quit worrying about your hdf5 setups/compiler combinations, it is safe to say
that this is definitely not an hdf5 problem. It appears this library error
happens in both 2d and 3d cases, but only on the first checkpoint file, on our
SGI's anyway the code continues to run and produce additional checkpoint and
plotfiles without producing the hdf5 library error output. I haven't looked at
the data to see if it makes sense, but can you verify whether or not your run
actually stops or not? I have included the flash.par I have used in these test
cases, in both 2d and 3d 8 checkpoint files are produced and 7 plotfiles are
produced with this flash.par (I do 50 steps). In the 3d case I set maxblocks=2000
and compiled it in 64-bit using hdf5-1.4.5 (not post2), in the 32-bit runs I'm
using hdf5-1.4.3.

I will look at this closer tommorow to see why the first checkpoint file is
producing this error and let you know what I find out.

--Brad

Tomasz Plewa wrote:

> Markus -
>
> It is true that serial HDF5 version is default in FLASH - you can
> check in your Modules file (created by setup in FLASH root directory).
> And I am positive serial is also default when building HDF5.
>
> I am copying Brad Gallagher on your message. Brad has lots of
> experience with HDF and sharing rest of your observations with him
> offers greatest chance to get some sensible answer. If that fails, then
> I think flash-users is the place to post a summary.
>
> Brad - do any issue/question raised by Markus ring a bell?
>
> Tomek
> --
> On Wed, Jun 18, 2003 at 10:16:40PM +0100, M.S.Gross@hw.ac.uk wrote:
> > Hi!
> >
> > I give it up for today. I think I had all combination by now. Even tried the
> > prebuild binaries, same thing.
> > Did you have a look into my flash.log file? The serial hdf5 is default,
> > isn't it? At least I did the usual -3d -auto etc, nothing about i/o
> >
> > My last attempt is to try to get hdf5 running with fortran enabled and ifc -
> > seems to be not my day today (the lift even dropped me off at the wrong
> > floor earlier ;-)
> >
> > I got a testprogram running with hdf5 on sgi, worked fine until I queried it
> > for the dimensions of a dataset, well it got it nearly right but one
> > dimension was several thousand times off the mark. From what I've seen (and
> > I have not understood a lot) in the error output generated by flash (of
> > course rather hdf5 in flash) there was something about zero sized dimensions
> > ....
> > Would you mind asking your systems person what exact version you are using,
> > pre-compiled or build fom source and if there were any tweaks? I mean it
> > really shouldn't be difficult, hdf4 was a peace of cake ...what are they
> > doing?
> >
> > Anyhow ... we'll see whats happening.
> >
> >
> > Markus.
> >
> >
> > On Wed, 18 Jun 2003 14:12:11 -0500, Tomasz Plewa <tomek@flash.uchicago.edu>
> > wrote:
> >
> > > OK - thanks for the warning, Markus. I am copying our system person
> > > on
> > > this message so we would not suffer as you do.
> > >
> > > And let us know what happens when you use the older version.
> > >
> > > Tomek
> > > --
> > > On Wed, Jun 18, 2003 at 07:51:08PM +0100, Markus Gross wrote:
> > > >
> > > > We have the 7.4 compiler - should never ever have asked for it
> > > ...
> > > >
> > > > On another system we have the 7.3.1.3m and it's compiling at the
> > > moment. Went
> > > > back to hdf5 1.4.4 as well, we'll see.
> > > >
> > > > So, you are warned not to upgrade your compiler ;-)
> > > >
> > > > Markus.
> > > >
> > > >
> > > > On Wednesday 18 June 2003 19:43, you wrote:
> > > > > > Just a short update: no joy.
> > > > >
> > > > > This is sad, actually.
> > > > >
> > > > > > I am trying an older compiler, we'll see.
> > > > >
> > > > > Hmm. Given we use it every day, I would expect -n32 working
> > > for
> > > > > us.
> > > > >
> > > > > For the record, on our SGI systems we have 7.3.1.3m and we are
> > > running
> > > > > IRIX 6.5.16m.
> > > > >
> > > > > Tomek
> > > >
> > > > --
> > > > _______________________________________________________________
> > > >
> > > > Markus Gross AMIMechE BEng (Hons.) Mechanical Engineering
> > > >
> > > > Heriot Watt University Edinburgh
> > > > School of Engineering and Physical Sciences
> > > > James Nasmyth Building
> > > > Edinburgh
> > > > EH14 4AS
> > > > UK
> > > >
> > > > Member of IMechE, SPIE, CSME and VDI
> > > > _______________________________________________________________
> > > >
> > > > further contact:
> > > >
> > > > Phone : +44 (0) 131 451 4737
> > > >
> > > > UNiX talk: talk markus@lasersim.mce.hw.ac.uk
> > > >
> > > > _______________________________________________________________
> > > >
> > > > "Plans are a place to begin," Grove said. "They rarely deliver
> > > > you to where you expect. Make your plans knowing you are going
> > > > to throw them away."
> > > >
> > > > _______________________________________________________________
> > > >
> > > >
> > > >
> > >
> > > --
> > >
> >
> >
> >
> >
> >
> > ________________________________________________________________
> >
> > DISCLAIMER:
> >
> > This e-mail and any files transmitted with it are confidential
> > and intended solely for the use of the individual or entity to
> > whom it is addressed. If you are not the intended recipient
> > you are prohibited from using any of the information contained
> > in this e-mail. In such a case, please destroy all copies in
> > your possession and notify the sender by reply e-mail. Heriot
> > Watt University does not accept liability or responsibility
> > for changes made to this e-mail after it was sent, or for
> > viruses transmitted through this e-mail. Opinions, comments,
> > conclusions and other information in this e-mail that do not
> > relate to the official business of Heriot Watt University are
> > not endorsed by it.
> > ________________________________________________________________
>
> --

--
Brad Gallagher
ASCI Flash Center
jbgallag@flash.uchicago.edu

# Runtime parameters for the Emery wind tunnel + step problem.

# Parameters for initial model

# Ambient pressure and density and inflow velocity.

p_ambient = 1.0
rho_ambient = 1.4
wind_vel = 3.0

# Gas ratio of specific heats

gamma = 1.4

# Computational volume parameters

# Grid geometry

geometry = "cartesian"

# Size of computational volume

Nblockx = 15
Nblocky = 4
xmin = 0.
xmax = 3.
ymin = 0.2
ymax = 1.0

# Boundary conditions

xl_boundary_type = "user"
xr_boundary_type = "outflow"

yl_boundary_type = "reflect"
yr_boundary_type = "reflect"

# Simulation (grid, time, I/O) parameters

cfl = 0.8
lrefine_max = 4
basenm = "windtunnel_4lev_"
restart = .false.
trstrt = 0.005
tplot = 0.005
nend = 50
tmax = 4.0
eint_switch = 1.e-4
Received on Wed Jun 18 19:07:04 2003

This archive was generated by hypermail 2.1.8 : Thu Aug 31 2006 - 21:20:48 CDT