From justin-parsons at uiowa.edu  Wed Oct  1 21:06:07 2008
From: justin-parsons at uiowa.edu (Justin T Parsons)
Date: Wed, 1 Oct 2008 21:06:07 -0500
Subject: [FLASH-USERS] error in compiling Sedov example - FIXED
Message-ID: <db005d60810011906x55e0ce35i2f7401d43313eb9@mail.gmail.com>

Hello

Here is an update on a problem I had a while back.

After putting the problem on the back burner for quite a while I revisited
it this week.  I fiddled about for a while and I found that building HDF5
(1.6.7) from source eliminated the error.  Oddly enough, I encountered this
error on two very different machines.

Cheers,
:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-
Justin Parsons
http://jussn.beevomit.org
:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-


On Tue, Aug 19, 2008 at 4:37 PM, Paul M. Rich <richp at flash.uchicago.edu>wrote:

> Justin,
>
> I've seen things like this happen like this before and these look like
> they are from libpthread.  Effectively it is a dependency of a
> dependency.  Are you linking statically or dynamically in your
> Makefile.h?  You can try manually including that library in your
> Makefile.h to ensure that these symbols are defined.
>
> Does that help?
>
> Paul Rich
> --------------------------------
> richp at flash.uchicago.edu
> ASC Flash Center
> University of Chicago
>
>
> Parsons, Justin T wrote:
> > Greetings!
> >
> > I'm in the process of testing my FLASH install and familiarizing myself
> with the code.  I've been trying to compile the Sedov problem but keep
> running in to this error:
> >
> > --ERROR--
> > /home/jussn/mpich2-install/lib/libmpich.a(simple_pmi.o): In function
> `PMI_Init':
> > simple_pmi.c:(.text+0x1fcd): warning: Using 'gethostbyname' in statically
> linked applicatio
> > ns requires at runtime the shared libraries from the glibc version used
> for linking
> > /usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../lib/librt.a(aio_misc.o): In
> function `__aio_e
> > nqueue_request':
> > (.text+0x1c3): undefined reference to `pthread_getschedparam'
> > /usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../lib/librt.a(aio_misc.o): In
> function `__aio_e
> > nqueue_request':
> > (.text+0x2dd): undefined reference to `pthread_cond_signal'
> > /usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../lib/librt.a(aio_misc.o): In
> function `__aio_e
> > nqueue_request':
> > (.text+0x3f7): undefined reference to `pthread_attr_init'
> > /usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../lib/librt.a(aio_misc.o): In
> function `__aio_e
> > nqueue_request':
> > (.text+0x407): undefined reference to `pthread_attr_setdetachstate'
> > /usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../lib/librt.a(aio_misc.o): In
> function `__aio_e
> > nqueue_request':
> > (.text+0x41c): undefined reference to `pthread_attr_setstacksize'
> > /usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../lib/librt.a(aio_misc.o): In
> function `__aio_e
> > nqueue_request':
> > (.text+0x489): undefined reference to `pthread_attr_destroy'
> > /usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../lib/librt.a(aio_misc.o): In
> function `handle_
> > fildes_io':
> > (.text+0x676): undefined reference to `pthread_getschedparam'
> > /usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../lib/librt.a(aio_misc.o): In
> function `handle_
> > fildes_io':
> > (.text+0x6bd): undefined reference to `pthread_setschedparam'
> > /usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../lib/librt.a(aio_misc.o): In
> function `handle_
> > fildes_io':
> > (.text+0x790): undefined reference to `pthread_cond_signal'
> > /usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../lib/librt.a(aio_misc.o): In
> function `handle_
> > fildes_io':
> > (.text+0x9d1): undefined reference to `pthread_attr_init'
> > /usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../lib/librt.a(aio_misc.o): In
> function `handle_
> > fildes_io':
> > (.text+0x9e1): undefined reference to `pthread_attr_setdetachstate'
> > /usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../lib/librt.a(aio_misc.o): In
> function `handle_
> > fildes_io':
> > (.text+0xa7c): undefined reference to `pthread_cond_timedwait'
> > /usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../lib/librt.a(aio_notify.o):
> In function `__aio
> > _notify_only':
> > (.text+0xa9): undefined reference to `pthread_attr_init'
> > /usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../lib/librt.a(aio_notify.o):
> In function `__aio
> > _notify_only':
> > (.text+0xb9): undefined reference to `pthread_attr_setdetachstate'
> > collect2: ld returned 1 exit status
> > make: *** [flash3] Error 1
> > --ERROR--
> >
> > I'm not quite sure where to go from here.  Makefile.h in my "object" dir
> has the correct paths and, I believe, I've installed all necessary libraries
> and deps.  Any tips?
> >
> > System is Ubuntu 8.04 with AMD 32bit.
> >
> >
> > Cheers
> > Justin Parsons
> > http://jussn.beevomit.org
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://flash.uchicago.edu/pipermail/flash-users/attachments/20081001/0d1a0132/attachment.html 

From dubey at flash.uchicago.edu  Thu Oct  2 15:46:04 2008
From: dubey at flash.uchicago.edu (Anshu Dubey)
Date: Thu, 2 Oct 2008 15:46:04 -0500
Subject: [FLASH-USERS] FLASH3.1 Release
Message-ID: <5b942a610810021346o92a26dcsba7f43d3b37d8066@mail.gmail.com>

The Flash Center is pleased to announce the release of the
next version of the FLASH code, version 3.1. FLASH 3.1 offers
many new features, and a few bug-fixes  added since FLASH 3.0 release.
The new features of FLASH 3.1 are :

* Support for Paramesh 4, which includes operation of Paramesh in
 library mode.

* Major performance improvement in the Particles data movement algorithm
 released with 3.0, and a new Particles data movement algorithm which is
 more efficient in some situations.

* Support for multiple particle types in a single simulation. This has
 had limited testing.

* An algorithm to map paramesh grid to uniform grid which, when coupled
 with the multigrid solver, permits the coarse grid exact solve at
 higher resolution in parallel. This could significantly improve the
 scalability of the multigrid solver.

* Enhancement in the IO unit to permit splitting of a single checkpoint
 or plotfile. This feature is included to enable scalability of parallel
 file write on hundreds of thousands of processors.

* Fully supported implementations of Ionize, conductivity, viscosity
and diffusion.

* Reorganization of the Hydro and Driver units to better architect the
split versus un-split time integration.

* Enhancement in the Logfile unit to allow any processor in the simulation to
 be able to create and write into a private logfile. This feature is
 useful in gathering extra information from single/few processor
 failures when those failures do not occur on the master processor.


The FLASH3.1 release is available for download with a license agreement
at:

http://flash.uchicago.edu/website/download/

A stripped down version of FLASH3 that may be downloaded without a
license is also available at the same location. This version is
essentially the FLASH framework without any implementations.
Flash Center is also providing support for "add-ons" to the
code. Please see the section on "What's new in this release" in the
first chapter of the user's guide for details.


Additionally, the FLASH testing software FlashTest, which became
available with the alpha release, continues to be available for
download at:

http://flash.uchicago.edu/website/codesupport/

Many, but not all parts of FLASH3 are backwards-compatible with
FLASH2.  The Flash code group has written extensive documentation
detailing how to make the transition from FLASH2 to FLASH3 as smooth
as possible.  The user should look to:

http://flash.uchicago.edu/website/codesupport/

The website also contains other documentation including
a user's guide and a developer's section.  A new feature in FLASH3
documentation is the online description of the public interface
routines to various code units.


FLASH should be portable to most UNIX-like operating systems with a
python interpreter, Fortran 90 compiler,  C compiler and MPI library.
Please see the RELEASE-NOTES included in the FLASH source home
directory for a list of compilers, platforms and
library versions that are known to be compatible with FLASH.

FLASH output can be visualized using VisIt, a free interactive
visualization tool developed by Lawrence Livermore National
Laboratories under the ASCI initiative. VisIt is available from

http://flash.uchicago.edu/website/codesupport/visit, and
https://wci.llnl.gov/codes/visit

Development of the FLASH Code was funded by the DOE-supported
ASC/Alliance Center for Astrophysical Thermonuclear Flashes.  We
acknowledge support received from Lawrence Livermore National
Laboratory and the University of Chicago.

All publications resulting from the use of the FLASH Code must
acknowledge the ASC/Alliance Center for Astrophysical Thermonuclear
Flashes.  Addition of the following text to the paper acknowledgments
will be sufficient.

       "The software used in this work was in part developed by the
       DOE-supported ASC/Alliance Center for Astrophysical Thermonuclear
       Flashes at the University of Chicago."


From justin-parsons at uiowa.edu  Mon Oct 13 11:30:49 2008
From: justin-parsons at uiowa.edu (Justin T Parsons)
Date: Mon, 13 Oct 2008 11:30:49 -0500
Subject: [FLASH-USERS] setting up an extended source
Message-ID: <db005d60810130930vc34459dvad04f7b5e420f1ef@mail.gmail.com>

Hello Flash Users,

I'm trying to set up a simulation with an extended source of a spherically
symmetric flow.  At the moment I'm only worried about 2d.  Has anyone had
any experience setting something like this up?  I've picked around at the
examples and can't seem to figure out how one would define such a flow.
Thanks for any input!

Cheers,
:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-
Justin Parsons
http://jussn.beevomit.org
:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://flash.uchicago.edu/pipermail/flash-users/attachments/20081013/dbc65247/attachment.html 

From latife at astro.rug.nl  Mon Oct 13 14:51:14 2008
From: latife at astro.rug.nl (M.A. Latife)
Date: Mon, 13 Oct 2008 21:51:14 +0200
Subject: [FLASH-USERS] saving  the data of all blocks and refinement
Message-ID: <48F3A6B2.4020705@astro.rug.nl>

Hi
Dear All,
I want to save the value of density and temperature of all blocks at 
previous time to use them in EOS3d.F90.
I am saving the values of temperature and density in 
Hydro_sweep.F90.Unksm,This scratch array stores the values of internal 
zones only not guard cells.Can i save data at previous time step not 
only interior zones but guard cells as well?
I am saving these values before calls are made for hydro_1d and 
update_soln.it seems me that density is updated while calling 
hydro_1d.F90. am i right? if not then where density is updated.
My second question.
When refinement takes place and more blocks are added at new time step 
but i have zero values in  newly added blocks as i  save data before 
calls are made to hydro_1d and update_soln.f90 at previous time step.How 
FLASH handles these newly added blocks( i think takes data from parent 
block) .How can i avoid these zero values in newly added blocks and add 
proper vales in them?
Any idea?

 What i am doing is following
 
do block_no = 1, lnblocks

       if (dBaseNodeType(block_no) .eq. 1) then

          unk1blk => dBaseGetDataPtrSingleBlock( block_no, GC )

! save the old temperature and  density

          do k = nguard*k3d+1, nguard*k3d+nzb
             do j = nguard*k2d+1, nguard*k2d+nyb
                do i = nguard+1, nguard+nxb
                   unksm(itemp_old,i,j,k,block_no) = unk1blk(itemp,i,j,k)
           unksm(idens_old,i,j,k,block_no) = unk1blk(idens,i,j,k)
       
                enddo
             enddo
          enddo

Thanks in advance
Kind Regards
Latif









From bperret at asu.edu  Thu Oct 16 14:01:26 2008
From: bperret at asu.edu (Beatrice Perret)
Date: Thu, 16 Oct 2008 12:01:26 -0700
Subject: [FLASH-USERS] Pb while using gmake on the Sedov example
Message-ID: <69f3c8d10810161201k491f2bccu1bbe5277bb1662d4@mail.gmail.com>

Hello flash users

I am trying to move from flash2.5 to flash3.1. I am encountering a
problem while running the make for the Sedov example.

Here is the whole message I am getting after typing gmake:

Calculating dependencies
./setup depends.py --generateINTERMEDIATElines -I
/usr/local/mpich2/default/bin/include -c -r8 -i4 -O3 -I
/usr/local/hdf5/hdf5-1.8.1:/usr/local/szip-2.1/include -I
/usr/local/mpich2/default/bin/include -c -O2 *.f *.f90 *.F90 *.F
./setup_addcdepends.py -I
/usr/local/hdf5/hdf5-1.8.1:/usr/local/szip-2.1/include -I
/usr/local/mpich2/default/bin/include -c -O2 *.c
Makefile.Depend:10 *** target pattern contains no %. Stop.

I have compared the Makefile.h for my machine with the one a colleague
is using with 3.0. It is similar. It is also working fine with
flash2.5.

I have looked at the content of Makefile.Depend, It is similar to the
one my colleague gets and ends with the line "Flash.o:"

Any idea or suggestion?

Thanks,

Beatrice
-- 
Beatrice Perret
Department of Physics
Arizona State University
P.O. Box 871504
Tempe, AZ 85287-1504


From klaus at flash.uchicago.edu  Thu Oct 16 15:38:00 2008
From: klaus at flash.uchicago.edu (Klaus Weide)
Date: Thu, 16 Oct 2008 15:38:00 -0500 (CDT)
Subject: [FLASH-USERS] Pb while using gmake on the Sedov example
In-Reply-To: <69f3c8d10810161201k491f2bccu1bbe5277bb1662d4@mail.gmail.com>
References: <69f3c8d10810161201k491f2bccu1bbe5277bb1662d4@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.0810161530001.23212@flash.uchicago.edu>

On Thu, 16 Oct 2008, Beatrice Perret wrote:

> I am trying to move from flash2.5 to flash3.1. I am encountering a
> problem while running the make for the Sedov example.
>
> Here is the whole message I am getting after typing gmake:
>
> Calculating dependencies
> ./setup depends.py --generateINTERMEDIATElines -I
> /usr/local/mpich2/default/bin/include -c -r8 -i4 -O3 -I
> /usr/local/hdf5/hdf5-1.8.1:/usr/local/szip-2.1/include -I
> /usr/local/mpich2/default/bin/include -c -O2 *.f *.f90 *.F90 *.F
> ./setup_addcdepends.py -I
> /usr/local/hdf5/hdf5-1.8.1:/usr/local/szip-2.1/include -I
> /usr/local/mpich2/default/bin/include -c -O2 *.c
> Makefile.Depend:10 *** target pattern contains no %. Stop.
>
> I have compared the Makefile.h for my machine with the one a colleague
> is using with 3.0. It is similar. It is also working fine with
> flash2.5.
>
> I have looked at the content of Makefile.Depend, It is similar to the
> one my colleague gets and ends with the line "Flash.o:"
>
>
> Any idea or suggestion?

Beatrice,

What is on line 10 of the Makefile.Depend?  Perhaps you
could sent me the first 10 or so lines.

Also, are you perhaps using an unusual version of GNU make,
what is the output from 'gmake --version' ?


Klaus


From jfg at ucolick.org  Mon Oct 20 04:30:37 2008
From: jfg at ucolick.org (James Guillochon)
Date: Mon, 20 Oct 2008 02:30:37 -0700
Subject: [FLASH-USERS] XFlash Bug Fixes
Message-ID: <48FC4FBD.6010605@ucolick.org>

Hi guys,

Some missing code in one of the XFlash support routines was causing me 
intermittent problems for a long time, so I figured I'd share the fix in 
case anyone else was getting the same problem. Basically, whoever wrote 
the routine forgot to include a couple H5_CLOSE (such as "H5T_CLOSE, 
datatype") commands, which are necessary to avoid memory leaks! The 
omissions I found were in the determine_file_version.pro and 
read_amr.pro routines, both essential to XFlash. Here's the location of 
the missing commands:

determine_file_version.pro:
Missing "H5T_CLOSE, datatype" after "H5D_GET_TYPE", should be inserted 
after "H5D_CLOSE, dataset" line.
"H5F_CLOSE" command appears inside if statement, it should be OUTSIDE 
the if statement, otherwise it isn't guaranteed to execute!

read_amr.pro:
"H5F_CLOSE" command appears inside if statement, it should be OUTSIDE 
the if statement.

This was causing me a huge headache and a memory corruption issue which 
would rear itself only occasionally, but would result in the wrong file 
being read! Very annoying when you're looping over hundreds of dumps...

-- 

James Guillochon
Department of Astronomy & Astrophysics
University of California, Santa Cruz
jfg at ucolick.org


From seyit at astro.rug.nl  Mon Oct 20 06:27:12 2008
From: seyit at astro.rug.nl (Seyit Hocuk)
Date: Mon, 20 Oct 2008 13:27:12 +0200
Subject: [FLASH-USERS] XFlash Bug Fixes
In-Reply-To: <48FC4FBD.6010605@ucolick.org>
References: <48FC4FBD.6010605@ucolick.org>
Message-ID: <48FC6B10.2020207@astro.rug.nl>

Hi James,

I am glad you found it though for yourself and everybody else. It is 
especially good that you share this with all of us. Personally, I didn't 
encounter this problem, but might have in the future.

Kind Regards,
Seyit



James Guillochon wrote:
> Hi guys,
>
> Some missing code in one of the XFlash support routines was causing me 
> intermittent problems for a long time, so I figured I'd share the fix 
> in case anyone else was getting the same problem. Basically, whoever 
> wrote the routine forgot to include a couple H5_CLOSE (such as 
> "H5T_CLOSE, datatype") commands, which are necessary to avoid memory 
> leaks! The omissions I found were in the determine_file_version.pro 
> and read_amr.pro routines, both essential to XFlash. Here's the 
> location of the missing commands:
>
> determine_file_version.pro:
> Missing "H5T_CLOSE, datatype" after "H5D_GET_TYPE", should be inserted 
> after "H5D_CLOSE, dataset" line.
> "H5F_CLOSE" command appears inside if statement, it should be OUTSIDE 
> the if statement, otherwise it isn't guaranteed to execute!
>
> read_amr.pro:
> "H5F_CLOSE" command appears inside if statement, it should be OUTSIDE 
> the if statement.
>
> This was causing me a huge headache and a memory corruption issue 
> which would rear itself only occasionally, but would result in the 
> wrong file being read! Very annoying when you're looping over hundreds 
> of dumps...
>



From seyit at astro.rug.nl  Mon Oct 20 06:37:34 2008
From: seyit at astro.rug.nl (Seyit Hocuk)
Date: Mon, 20 Oct 2008 13:37:34 +0200
Subject: [FLASH-USERS] XFlash Bug Fixes
In-Reply-To: <48FC4FBD.6010605@ucolick.org>
References: <48FC4FBD.6010605@ucolick.org>
Message-ID: <48FC6D7E.3080503@astro.rug.nl>

One more thing,

I think you might mean "file_information.pro" instead of 
"determine_file_version.pro", because only place where
"H5T_CLOSE" and "H5D_GET_TYPE" are appearing are in the files 
"file_information.pro" and "read_amr.pro".




James Guillochon wrote:
> Hi guys,
>
> Some missing code in one of the XFlash support routines was causing me 
> intermittent problems for a long time, so I figured I'd share the fix 
> in case anyone else was getting the same problem. Basically, whoever 
> wrote the routine forgot to include a couple H5_CLOSE (such as 
> "H5T_CLOSE, datatype") commands, which are necessary to avoid memory 
> leaks! The omissions I found were in the determine_file_version.pro 
> and read_amr.pro routines, both essential to XFlash. Here's the 
> location of the missing commands:
>
> determine_file_version.pro:
> Missing "H5T_CLOSE, datatype" after "H5D_GET_TYPE", should be inserted 
> after "H5D_CLOSE, dataset" line.
> "H5F_CLOSE" command appears inside if statement, it should be OUTSIDE 
> the if statement, otherwise it isn't guaranteed to execute!
>
> read_amr.pro:
> "H5F_CLOSE" command appears inside if statement, it should be OUTSIDE 
> the if statement.
>
> This was causing me a huge headache and a memory corruption issue 
> which would rear itself only occasionally, but would result in the 
> wrong file being read! Very annoying when you're looping over hundreds 
> of dumps...
>



From jfg at ucolick.org  Mon Oct 20 10:13:44 2008
From: jfg at ucolick.org (James Guillochon)
Date: Mon, 20 Oct 2008 08:13:44 -0700
Subject: [FLASH-USERS] XFlash Bug Fixes
In-Reply-To: <48FC6D7E.3080503@astro.rug.nl>
References: <48FC4FBD.6010605@ucolick.org> <48FC6D7E.3080503@astro.rug.nl>
Message-ID: <48FCA028.508@ucolick.org>

There is an issue in "determine_file_version.pro" on line 44 (I just 
checked the FLASH 3.1 distro), that H5D_GET_TYPE statement doesn't have 
a corresponding close statement. The other issue was that the H5F_CLOSE 
command should appear outside of the if-else since the file is opened 
outside of the if-else.

I'm looking at "file_information.pro" and I see that there are a couple 
of missing close statements there as well, specifically lines 148 & 149 
which have no close statements.

James Guillochon
Department of Astronomy & Astrophysics
University of California, Santa Cruz
jfg at ucolick.org

Seyit Hocuk wrote:
> One more thing,
> 
> I think you might mean "file_information.pro" instead of 
> "determine_file_version.pro", because only place where
> "H5T_CLOSE" and "H5D_GET_TYPE" are appearing are in the files 
> "file_information.pro" and "read_amr.pro".
> 
> 
> 
> 
> James Guillochon wrote:
>> Hi guys,
>>
>> Some missing code in one of the XFlash support routines was causing me 
>> intermittent problems for a long time, so I figured I'd share the fix 
>> in case anyone else was getting the same problem. Basically, whoever 
>> wrote the routine forgot to include a couple H5_CLOSE (such as 
>> "H5T_CLOSE, datatype") commands, which are necessary to avoid memory 
>> leaks! The omissions I found were in the determine_file_version.pro 
>> and read_amr.pro routines, both essential to XFlash. Here's the 
>> location of the missing commands:
>>
>> determine_file_version.pro:
>> Missing "H5T_CLOSE, datatype" after "H5D_GET_TYPE", should be inserted 
>> after "H5D_CLOSE, dataset" line.
>> "H5F_CLOSE" command appears inside if statement, it should be OUTSIDE 
>> the if statement, otherwise it isn't guaranteed to execute!
>>
>> read_amr.pro:
>> "H5F_CLOSE" command appears inside if statement, it should be OUTSIDE 
>> the if statement.
>>
>> This was causing me a huge headache and a memory corruption issue 
>> which would rear itself only occasionally, but would result in the 
>> wrong file being read! Very annoying when you're looping over hundreds 
>> of dumps...
>>
> 
> 
> !DSPAM:10135,48fc6d8022189021468!
> 


From bperret at asu.edu  Tue Oct 21 19:26:31 2008
From: bperret at asu.edu (Beatrice Perret)
Date: Tue, 21 Oct 2008 17:26:31 -0700
Subject: [FLASH-USERS] Fwd: Pb while using gmake on the Sedov example (fwd)
In-Reply-To: <Pine.LNX.4.64.0810201015490.13876@flash.uchicago.edu>
References: <Pine.LNX.4.64.0810201015490.13876@flash.uchicago.edu>
Message-ID: <69f3c8d10810211726x3437be95p4622872d82faf366@mail.gmail.com>

Hello flash-users

Here is the exchange I had recently with Klaus Weide following the
question about using gmake on the Sedov example for flash3.1. I
unfortunately hit "reply" instead of "reply-to-all". I am posting this
again in case other people have encountered the same kind of problem.

Beatrice


---------- Forwarded message ----------
From: Klaus Weide <klaus at flash.uchicago.edu>
Date: Mon, Oct 20, 2008 at 8:21 AM
Subject: Re: [FLASH-USERS] Pb while using gmake on the Sedov example (fwd)
To: "Paul M. Rich" <richp at flash.uchicago.edu>
Cc: beatrice.perret at asu.edu


Beatrice,

Thank you for reporting back your findings.  If I understand you
right, you are now able to use FLASH3.1, by using HDF5 version 1.6.5.

I am forwarding your message to Paul Rich, who has a better understanding
of library versions.  I think such failures to build FLASH with certain
library versions have been reported before.

You may also want to consider reporting your findings back to the
flash-users list.

Again thanks,

Klaus
---------- Forwarded message ----------
Date: Fri, 17 Oct 2008 13:52:47 -0700
From: Beatrice Perret <bperret at asu.edu>
Reply-To: beatrice.perret at asu.edu
To: Klaus Weide <klaus at flash.uchicago.edu>
Subject: Re: [FLASH-USERS] Pb while using gmake on the Sedov example

Klaus

I followed the same step as the ones above (previous email) for
FLASH3.0 and got the same errors. I think this is expected.

I tried the new Makefile.h with Flash2.5, but using the version
hdf5-1.6.5, since this is the only version of hdf5 that works. The
compilation was successful.

Then I changed the version of hdf5 from 1.6.7 to 1.6.5 for Flash3.1
and the compilation was successful.

Here are the options I used to configure each hdf5 version:
hdf5-1.6.5 and hdf5-1.6.7:
./configure --prefix=/...(whatever) --with-szlib=/usr/local/szip-2.1
--disable-shared CPFLAGS=-fpic CPPFLAGS=-fPIC (both needed to use
visit)
hdf5-1.6.8:
./configure --prefix=/..(whatever) --with-szlib=/usr/local/szip-2.1
--disable-shared --enable-cxx CPFLAGS=-fPIC CPPFLAGS=-fPIC

Beatrice

On Fri, Oct 17, 2008 at 1:21 PM, Beatrice Perret <bperret at asu.edu> wrote:
>
> Klaus
>
> Thank you for fixing my Makefile.h. It works.
>
> Now I have a problem with the following:
> io_h5read_bflags.c(76): errore #165: too few arguments in function call
> dataset = H5Dopen(*file_identifier, "bflags");
> compilation aborted for io_h5read_bflags.c (code 2)
> (I was using hdf5-1.8.1)
>
> I switched to 1.6.7 and I am getting a lot of undefined reference to
> SZ_encoder_enabled, H5Z_filter_deflate, H5Zdeflate,
> H5Z_can_apply_szip, H5Z_filter_szip
>
> I don't know where the problem is coming from. Any idea would be great.
>
> Beatrice
>
> On Fri, Oct 17, 2008 at 8:57 AM, Klaus Weide <klaus at flash.uchicago.edu> wrote:
>>
>> On Thu, 16 Oct 2008, Beatrice Perret wrote:
>>
>>> I have attached the first 15 lines. But I have just noticed that line 10
>>> is
>>>
>>> /usr/local/hdf5/hdf5-1.6.5:/usr/local/szip-2.1/include.o:
>>>
>>> I assumed that what is expected is:
>>>
>>> /usr/local/hdf5/hdf5-1.6.5/include.o
>>> /usr/local/szip-2.1/include.o
>>>
>>> Right?
>>
>> Beatrice,
>>
>> Actually I think there isn't really any need for having this in the
>> Makefile.Depend in any form.  You should be able to just delete the
>> line
>>  /usr/local/hdf5/hdf5-1.6.5:/usr/local/szip-2.1/include.o:
>> and then make should work.
>>
>> The line in the Makefile.Depends is a result of this line in your
>> Makefile.h:
>>  HDF5_PATH = /usr/local/hdf5/hdf5-1.8.1:/usr/local/szip-2.1
>>
>> The setup_depends.py utility (which gets invoked automatically from make)
>> tries to analyze the command line flags used for invoking the Fortran
>> compiler, but it doesn't do a good job of it in this case;
>> apparently it doesn't expect that any command line arguments,
>> like -I /usr/local/hdf5/hdf5-1.8.1:/usr/local/szip-2.1/include,
>> contain colons.
>>
>> I suppose the setup_depends.py should be fixed.
>>
>>> In flash2.5 I could not feed szip using a different way than this. If
>>> this is the problem how should I do it for flash3.0 or 3.1? I have
>>> also attached the Makefile.h for my machine.
>>
>> If you just need to pass
>>  -I/usr/local/szip-2.1/include
>> to the compiler invocations (and/or add something like
>>  -L/usr/local/szip-2.1/lib
>> for the linking step?), then you should modify your Makefile.h so that
>>
>> 1) you have
>>  HDF5_PATH = /usr/local/hdf5/hdf5-1.8.1
>> 2) add -I/usr/local/szip-2.1/include explicitly in the line that defines
>>  CFLAGS_HDF5
>> 3) add -L/usr/local/szip-2.1/lib explicitly in the line that defines
>>  LIB_HDF5 (if needed).
>>
>> Hope this helps,
>>
>> Klaus
>>
>
>
>
> --
> Beatrice Perret
> Department of Physics
> Arizona State University
> P.O. Box 871504
> Tempe, AZ 85287-1504
>



--
Beatrice Perret
Department of Physics
Arizona State University
P.O. Box 871504
Tempe, AZ 85287-1504



-- 
Beatrice Perret
Department of Physics
Arizona State University
P.O. Box 871504
Tempe, AZ 85287-1504


From stratos at uiuc.edu  Wed Oct 22 07:52:26 2008
From: stratos at uiuc.edu (Stratos Boutloukos)
Date: Wed, 22 Oct 2008 08:52:26 -0400
Subject: [FLASH-USERS] Fwd: Pb while using gmake on the Sedov example
	(fwd)
In-Reply-To: <69f3c8d10810211726x3437be95p4622872d82faf366@mail.gmail.com>
References: <Pine.LNX.4.64.0810201015490.13876@flash.uchicago.edu>
	<69f3c8d10810211726x3437be95p4622872d82faf366@mail.gmail.com>
Message-ID: <4C70D2F0-2C90-4351-A7E4-41E4F42E6C53@uiuc.edu>

Hello Beatrice, Klaus, Paul and other flash-users,

When compiling flash3.1 I had also encountered similar problems with  
the libraries. The latest version of HDF5 (1.8.1) apparently has some  
new build-in functions that are not recognized by flash's current  
makefile. For more info see the hdf software changes from version to  
version:
http://www.hdfgroup.org/HDF5/doc/ADGuide/Changes.html
The latest version of HDF5 that works fine for me is 1.6.7 and that's  
what I use now.

Stratos

On Oct 21, 2008, at 8:26 PM, Beatrice Perret wrote:

> Hello flash-users
>
> Here is the exchange I had recently with Klaus Weide following the
> question about using gmake on the Sedov example for flash3.1. I
> unfortunately hit "reply" instead of "reply-to-all". I am posting this
> again in case other people have encountered the same kind of problem.
>
> Beatrice
>
>
> ---------- Forwarded message ----------
> From: Klaus Weide <klaus at flash.uchicago.edu>
> Date: Mon, Oct 20, 2008 at 8:21 AM
> Subject: Re: [FLASH-USERS] Pb while using gmake on the Sedov  
> example (fwd)
> To: "Paul M. Rich" <richp at flash.uchicago.edu>
> Cc: beatrice.perret at asu.edu
>
>
> Beatrice,
>
> Thank you for reporting back your findings.  If I understand you
> right, you are now able to use FLASH3.1, by using HDF5 version 1.6.5.
>
> I am forwarding your message to Paul Rich, who has a better  
> understanding
> of library versions.  I think such failures to build FLASH with  
> certain
> library versions have been reported before.
>
> You may also want to consider reporting your findings back to the
> flash-users list.
>
> Again thanks,
>
> Klaus
> ---------- Forwarded message ----------
> Date: Fri, 17 Oct 2008 13:52:47 -0700
> From: Beatrice Perret <bperret at asu.edu>
> Reply-To: beatrice.perret at asu.edu
> To: Klaus Weide <klaus at flash.uchicago.edu>
> Subject: Re: [FLASH-USERS] Pb while using gmake on the Sedov example
>
> Klaus
>
> I followed the same step as the ones above (previous email) for
> FLASH3.0 and got the same errors. I think this is expected.
>
> I tried the new Makefile.h with Flash2.5, but using the version
> hdf5-1.6.5, since this is the only version of hdf5 that works. The
> compilation was successful.
>
> Then I changed the version of hdf5 from 1.6.7 to 1.6.5 for Flash3.1
> and the compilation was successful.
>
> Here are the options I used to configure each hdf5 version:
> hdf5-1.6.5 and hdf5-1.6.7:
> ./configure --prefix=/...(whatever) --with-szlib=/usr/local/szip-2.1
> --disable-shared CPFLAGS=-fpic CPPFLAGS=-fPIC (both needed to use
> visit)
> hdf5-1.6.8:
> ./configure --prefix=/..(whatever) --with-szlib=/usr/local/szip-2.1
> --disable-shared --enable-cxx CPFLAGS=-fPIC CPPFLAGS=-fPIC
>
> Beatrice
>
> On Fri, Oct 17, 2008 at 1:21 PM, Beatrice Perret <bperret at asu.edu>  
> wrote:
>>
>> Klaus
>>
>> Thank you for fixing my Makefile.h. It works.
>>
>> Now I have a problem with the following:
>> io_h5read_bflags.c(76): errore #165: too few arguments in function  
>> call
>> dataset = H5Dopen(*file_identifier, "bflags");
>> compilation aborted for io_h5read_bflags.c (code 2)
>> (I was using hdf5-1.8.1)
>>
>> I switched to 1.6.7 and I am getting a lot of undefined reference to
>> SZ_encoder_enabled, H5Z_filter_deflate, H5Zdeflate,
>> H5Z_can_apply_szip, H5Z_filter_szip
>>
>> I don't know where the problem is coming from. Any idea would be  
>> great.
>>
>> Beatrice
>>
>> On Fri, Oct 17, 2008 at 8:57 AM, Klaus Weide  
>> <klaus at flash.uchicago.edu> wrote:
>>>
>>> On Thu, 16 Oct 2008, Beatrice Perret wrote:
>>>
>>>> I have attached the first 15 lines. But I have just noticed that  
>>>> line 10
>>>> is
>>>>
>>>> /usr/local/hdf5/hdf5-1.6.5:/usr/local/szip-2.1/include.o:
>>>>
>>>> I assumed that what is expected is:
>>>>
>>>> /usr/local/hdf5/hdf5-1.6.5/include.o
>>>> /usr/local/szip-2.1/include.o
>>>>
>>>> Right?
>>>
>>> Beatrice,
>>>
>>> Actually I think there isn't really any need for having this in the
>>> Makefile.Depend in any form.  You should be able to just delete the
>>> line
>>>  /usr/local/hdf5/hdf5-1.6.5:/usr/local/szip-2.1/include.o:
>>> and then make should work.
>>>
>>> The line in the Makefile.Depends is a result of this line in your
>>> Makefile.h:
>>>  HDF5_PATH = /usr/local/hdf5/hdf5-1.8.1:/usr/local/szip-2.1
>>>
>>> The setup_depends.py utility (which gets invoked automatically  
>>> from make)
>>> tries to analyze the command line flags used for invoking the  
>>> Fortran
>>> compiler, but it doesn't do a good job of it in this case;
>>> apparently it doesn't expect that any command line arguments,
>>> like -I /usr/local/hdf5/hdf5-1.8.1:/usr/local/szip-2.1/include,
>>> contain colons.
>>>
>>> I suppose the setup_depends.py should be fixed.
>>>
>>>> In flash2.5 I could not feed szip using a different way than  
>>>> this. If
>>>> this is the problem how should I do it for flash3.0 or 3.1? I have
>>>> also attached the Makefile.h for my machine.
>>>
>>> If you just need to pass
>>>  -I/usr/local/szip-2.1/include
>>> to the compiler invocations (and/or add something like
>>>  -L/usr/local/szip-2.1/lib
>>> for the linking step?), then you should modify your Makefile.h so  
>>> that
>>>
>>> 1) you have
>>>  HDF5_PATH = /usr/local/hdf5/hdf5-1.8.1
>>> 2) add -I/usr/local/szip-2.1/include explicitly in the line that  
>>> defines
>>>  CFLAGS_HDF5
>>> 3) add -L/usr/local/szip-2.1/lib explicitly in the line that defines
>>>  LIB_HDF5 (if needed).
>>>
>>> Hope this helps,
>>>
>>> Klaus
>>>
>>
>>
>>
>> --
>> Beatrice Perret
>> Department of Physics
>> Arizona State University
>> P.O. Box 871504
>> Tempe, AZ 85287-1504
>>
>
>
>
> --
> Beatrice Perret
> Department of Physics
> Arizona State University
> P.O. Box 871504
> Tempe, AZ 85287-1504
>
>
>
> -- 
> Beatrice Perret
> Department of Physics
> Arizona State University
> P.O. Box 871504
> Tempe, AZ 85287-1504



From bperret at asu.edu  Wed Oct 22 13:55:15 2008
From: bperret at asu.edu (Beatrice Perret)
Date: Wed, 22 Oct 2008 11:55:15 -0700
Subject: [FLASH-USERS] Fwd: Pb while using gmake on the Sedov example
	(fwd)
In-Reply-To: <4C70D2F0-2C90-4351-A7E4-41E4F42E6C53@uiuc.edu>
References: <Pine.LNX.4.64.0810201015490.13876@flash.uchicago.edu>
	<69f3c8d10810211726x3437be95p4622872d82faf366@mail.gmail.com>
	<4C70D2F0-2C90-4351-A7E4-41E4F42E6C53@uiuc.edu>
Message-ID: <69f3c8d10810221155h4aeacd81n1853b179f20b99b4@mail.gmail.com>

Stratos

Are you also using szip for compression with 1.6.7? My problem seems
to reside with this part.

Beatrice

On Wed, Oct 22, 2008 at 5:52 AM, Stratos Boutloukos <stratos at uiuc.edu> wrote:
> Hello Beatrice, Klaus, Paul and other flash-users,
>
> When compiling flash3.1 I had also encountered similar problems with the
> libraries. The latest version of HDF5 (1.8.1) apparently has some new
> build-in functions that are not recognized by flash's current makefile. For
> more info see the hdf software changes from version to version:
> http://www.hdfgroup.org/HDF5/doc/ADGuide/Changes.html
> The latest version of HDF5 that works fine for me is 1.6.7 and that's what I
> use now.
>
> Stratos
>
> On Oct 21, 2008, at 8:26 PM, Beatrice Perret wrote:
>
>> Hello flash-users
>>
>> Here is the exchange I had recently with Klaus Weide following the
>> question about using gmake on the Sedov example for flash3.1. I
>> unfortunately hit "reply" instead of "reply-to-all". I am posting this
>> again in case other people have encountered the same kind of problem.
>>
>> Beatrice
>>
>>
>> ---------- Forwarded message ----------
>> From: Klaus Weide <klaus at flash.uchicago.edu>
>> Date: Mon, Oct 20, 2008 at 8:21 AM
>> Subject: Re: [FLASH-USERS] Pb while using gmake on the Sedov example (fwd)
>> To: "Paul M. Rich" <richp at flash.uchicago.edu>
>> Cc: beatrice.perret at asu.edu
>>
>>
>> Beatrice,
>>
>> Thank you for reporting back your findings.  If I understand you
>> right, you are now able to use FLASH3.1, by using HDF5 version 1.6.5.
>>
>> I am forwarding your message to Paul Rich, who has a better understanding
>> of library versions.  I think such failures to build FLASH with certain
>> library versions have been reported before.
>>
>> You may also want to consider reporting your findings back to the
>> flash-users list.
>>
>> Again thanks,
>>
>> Klaus
>> ---------- Forwarded message ----------
>> Date: Fri, 17 Oct 2008 13:52:47 -0700
>> From: Beatrice Perret <bperret at asu.edu>
>> Reply-To: beatrice.perret at asu.edu
>> To: Klaus Weide <klaus at flash.uchicago.edu>
>> Subject: Re: [FLASH-USERS] Pb while using gmake on the Sedov example
>>
>> Klaus
>>
>> I followed the same step as the ones above (previous email) for
>> FLASH3.0 and got the same errors. I think this is expected.
>>
>> I tried the new Makefile.h with Flash2.5, but using the version
>> hdf5-1.6.5, since this is the only version of hdf5 that works. The
>> compilation was successful.
>>
>> Then I changed the version of hdf5 from 1.6.7 to 1.6.5 for Flash3.1
>> and the compilation was successful.
>>
>> Here are the options I used to configure each hdf5 version:
>> hdf5-1.6.5 and hdf5-1.6.7:
>> ./configure --prefix=/...(whatever) --with-szlib=/usr/local/szip-2.1
>> --disable-shared CPFLAGS=-fpic CPPFLAGS=-fPIC (both needed to use
>> visit)
>> hdf5-1.6.8:
>> ./configure --prefix=/..(whatever) --with-szlib=/usr/local/szip-2.1
>> --disable-shared --enable-cxx CPFLAGS=-fPIC CPPFLAGS=-fPIC
>>
>> Beatrice
>>
>> On Fri, Oct 17, 2008 at 1:21 PM, Beatrice Perret <bperret at asu.edu> wrote:
>>>
>>> Klaus
>>>
>>> Thank you for fixing my Makefile.h. It works.
>>>
>>> Now I have a problem with the following:
>>> io_h5read_bflags.c(76): errore #165: too few arguments in function call
>>> dataset = H5Dopen(*file_identifier, "bflags");
>>> compilation aborted for io_h5read_bflags.c (code 2)
>>> (I was using hdf5-1.8.1)
>>>
>>> I switched to 1.6.7 and I am getting a lot of undefined reference to
>>> SZ_encoder_enabled, H5Z_filter_deflate, H5Zdeflate,
>>> H5Z_can_apply_szip, H5Z_filter_szip
>>>
>>> I don't know where the problem is coming from. Any idea would be great.
>>>
>>> Beatrice
>>>
>>> On Fri, Oct 17, 2008 at 8:57 AM, Klaus Weide <klaus at flash.uchicago.edu>
>>> wrote:
>>>>
>>>> On Thu, 16 Oct 2008, Beatrice Perret wrote:
>>>>
>>>>> I have attached the first 15 lines. But I have just noticed that line
>>>>> 10
>>>>> is
>>>>>
>>>>> /usr/local/hdf5/hdf5-1.6.5:/usr/local/szip-2.1/include.o:
>>>>>
>>>>> I assumed that what is expected is:
>>>>>
>>>>> /usr/local/hdf5/hdf5-1.6.5/include.o
>>>>> /usr/local/szip-2.1/include.o
>>>>>
>>>>> Right?
>>>>
>>>> Beatrice,
>>>>
>>>> Actually I think there isn't really any need for having this in the
>>>> Makefile.Depend in any form.  You should be able to just delete the
>>>> line
>>>>  /usr/local/hdf5/hdf5-1.6.5:/usr/local/szip-2.1/include.o:
>>>> and then make should work.
>>>>
>>>> The line in the Makefile.Depends is a result of this line in your
>>>> Makefile.h:
>>>>  HDF5_PATH = /usr/local/hdf5/hdf5-1.8.1:/usr/local/szip-2.1
>>>>
>>>> The setup_depends.py utility (which gets invoked automatically from
>>>> make)
>>>> tries to analyze the command line flags used for invoking the Fortran
>>>> compiler, but it doesn't do a good job of it in this case;
>>>> apparently it doesn't expect that any command line arguments,
>>>> like -I /usr/local/hdf5/hdf5-1.8.1:/usr/local/szip-2.1/include,
>>>> contain colons.
>>>>
>>>> I suppose the setup_depends.py should be fixed.
>>>>
>>>>> In flash2.5 I could not feed szip using a different way than this. If
>>>>> this is the problem how should I do it for flash3.0 or 3.1? I have
>>>>> also attached the Makefile.h for my machine.
>>>>
>>>> If you just need to pass
>>>>  -I/usr/local/szip-2.1/include
>>>> to the compiler invocations (and/or add something like
>>>>  -L/usr/local/szip-2.1/lib
>>>> for the linking step?), then you should modify your Makefile.h so that
>>>>
>>>> 1) you have
>>>>  HDF5_PATH = /usr/local/hdf5/hdf5-1.8.1
>>>> 2) add -I/usr/local/szip-2.1/include explicitly in the line that defines
>>>>  CFLAGS_HDF5
>>>> 3) add -L/usr/local/szip-2.1/lib explicitly in the line that defines
>>>>  LIB_HDF5 (if needed).
>>>>
>>>> Hope this helps,
>>>>
>>>> Klaus
>>>>
>>>
>>>
>>>
>>> --
>>> Beatrice Perret
>>> Department of Physics
>>> Arizona State University
>>> P.O. Box 871504
>>> Tempe, AZ 85287-1504
>>>
>>
>>
>>
>> --
>> Beatrice Perret
>> Department of Physics
>> Arizona State University
>> P.O. Box 871504
>> Tempe, AZ 85287-1504
>>
>>
>>
>> --
>> Beatrice Perret
>> Department of Physics
>> Arizona State University
>> P.O. Box 871504
>> Tempe, AZ 85287-1504
>
>



-- 
Beatrice Perret
Department of Physics
Arizona State University
P.O. Box 871504
Tempe, AZ 85287-1504


From stratos at uiuc.edu  Wed Oct 22 14:48:08 2008
From: stratos at uiuc.edu (Stratos Boutloukos)
Date: Wed, 22 Oct 2008 15:48:08 -0400
Subject: [FLASH-USERS] Fwd: Pb while using gmake on the Sedov example
	(fwd)
In-Reply-To: <69f3c8d10810221155h4aeacd81n1853b179f20b99b4@mail.gmail.com>
References: <Pine.LNX.4.64.0810201015490.13876@flash.uchicago.edu>
	<69f3c8d10810211726x3437be95p4622872d82faf366@mail.gmail.com>
	<4C70D2F0-2C90-4351-A7E4-41E4F42E6C53@uiuc.edu>
	<69f3c8d10810221155h4aeacd81n1853b179f20b99b4@mail.gmail.com>
Message-ID: <6F94DC43-CAE5-41AD-A7A5-A99EDFA1367A@uiuc.edu>

Hi Beatrice,

zlib was used to built the HDF5 source libraries into our system by  
Peter Teuben. That's actually the default, so just leave out the szip  
part (--with-szlib=..) when configuring .

Stratos

On Oct 22, 2008, at 2:55 PM, Beatrice Perret wrote:

> Stratos
>
> Are you also using szip for compression with 1.6.7? My problem seems
> to reside with this part.
>
> Beatrice
>
> On Wed, Oct 22, 2008 at 5:52 AM, Stratos Boutloukos  
> <stratos at uiuc.edu> wrote:
>> Hello Beatrice, Klaus, Paul and other flash-users,
>>
>> When compiling flash3.1 I had also encountered similar problems  
>> with the
>> libraries. The latest version of HDF5 (1.8.1) apparently has some new
>> build-in functions that are not recognized by flash's current  
>> makefile. For
>> more info see the hdf software changes from version to version:
>> http://www.hdfgroup.org/HDF5/doc/ADGuide/Changes.html
>> The latest version of HDF5 that works fine for me is 1.6.7 and  
>> that's what I
>> use now.
>>
>> Stratos
>>
>> On Oct 21, 2008, at 8:26 PM, Beatrice Perret wrote:
>>
>>> Hello flash-users
>>>
>>> Here is the exchange I had recently with Klaus Weide following the
>>> question about using gmake on the Sedov example for flash3.1. I
>>> unfortunately hit "reply" instead of "reply-to-all". I am posting  
>>> this
>>> again in case other people have encountered the same kind of  
>>> problem.
>>>
>>> Beatrice
>>>
>>>
>>> ---------- Forwarded message ----------
>>> From: Klaus Weide <klaus at flash.uchicago.edu>
>>> Date: Mon, Oct 20, 2008 at 8:21 AM
>>> Subject: Re: [FLASH-USERS] Pb while using gmake on the Sedov  
>>> example (fwd)
>>> To: "Paul M. Rich" <richp at flash.uchicago.edu>
>>> Cc: beatrice.perret at asu.edu
>>>
>>>
>>> Beatrice,
>>>
>>> Thank you for reporting back your findings.  If I understand you
>>> right, you are now able to use FLASH3.1, by using HDF5 version  
>>> 1.6.5.
>>>
>>> I am forwarding your message to Paul Rich, who has a better  
>>> understanding
>>> of library versions.  I think such failures to build FLASH with  
>>> certain
>>> library versions have been reported before.
>>>
>>> You may also want to consider reporting your findings back to the
>>> flash-users list.
>>>
>>> Again thanks,
>>>
>>> Klaus
>>> ---------- Forwarded message ----------
>>> Date: Fri, 17 Oct 2008 13:52:47 -0700
>>> From: Beatrice Perret <bperret at asu.edu>
>>> Reply-To: beatrice.perret at asu.edu
>>> To: Klaus Weide <klaus at flash.uchicago.edu>
>>> Subject: Re: [FLASH-USERS] Pb while using gmake on the Sedov example
>>>
>>> Klaus
>>>
>>> I followed the same step as the ones above (previous email) for
>>> FLASH3.0 and got the same errors. I think this is expected.
>>>
>>> I tried the new Makefile.h with Flash2.5, but using the version
>>> hdf5-1.6.5, since this is the only version of hdf5 that works. The
>>> compilation was successful.
>>>
>>> Then I changed the version of hdf5 from 1.6.7 to 1.6.5 for Flash3.1
>>> and the compilation was successful.
>>>
>>> Here are the options I used to configure each hdf5 version:
>>> hdf5-1.6.5 and hdf5-1.6.7:
>>> ./configure --prefix=/...(whatever) --with-szlib=/usr/local/szip-2.1
>>> --disable-shared CPFLAGS=-fpic CPPFLAGS=-fPIC (both needed to use
>>> visit)
>>> hdf5-1.6.8:
>>> ./configure --prefix=/..(whatever) --with-szlib=/usr/local/szip-2.1
>>> --disable-shared --enable-cxx CPFLAGS=-fPIC CPPFLAGS=-fPIC
>>>
>>> Beatrice
>>>
>>> On Fri, Oct 17, 2008 at 1:21 PM, Beatrice Perret  
>>> <bperret at asu.edu> wrote:
>>>>
>>>> Klaus
>>>>
>>>> Thank you for fixing my Makefile.h. It works.
>>>>
>>>> Now I have a problem with the following:
>>>> io_h5read_bflags.c(76): errore #165: too few arguments in  
>>>> function call
>>>> dataset = H5Dopen(*file_identifier, "bflags");
>>>> compilation aborted for io_h5read_bflags.c (code 2)
>>>> (I was using hdf5-1.8.1)
>>>>
>>>> I switched to 1.6.7 and I am getting a lot of undefined  
>>>> reference to
>>>> SZ_encoder_enabled, H5Z_filter_deflate, H5Zdeflate,
>>>> H5Z_can_apply_szip, H5Z_filter_szip
>>>>
>>>> I don't know where the problem is coming from. Any idea would be  
>>>> great.
>>>>
>>>> Beatrice
>>>>
>>>> On Fri, Oct 17, 2008 at 8:57 AM, Klaus Weide  
>>>> <klaus at flash.uchicago.edu>
>>>> wrote:
>>>>>
>>>>> On Thu, 16 Oct 2008, Beatrice Perret wrote:
>>>>>
>>>>>> I have attached the first 15 lines. But I have just noticed  
>>>>>> that line
>>>>>> 10
>>>>>> is
>>>>>>
>>>>>> /usr/local/hdf5/hdf5-1.6.5:/usr/local/szip-2.1/include.o:
>>>>>>
>>>>>> I assumed that what is expected is:
>>>>>>
>>>>>> /usr/local/hdf5/hdf5-1.6.5/include.o
>>>>>> /usr/local/szip-2.1/include.o
>>>>>>
>>>>>> Right?
>>>>>
>>>>> Beatrice,
>>>>>
>>>>> Actually I think there isn't really any need for having this in  
>>>>> the
>>>>> Makefile.Depend in any form.  You should be able to just delete  
>>>>> the
>>>>> line
>>>>>  /usr/local/hdf5/hdf5-1.6.5:/usr/local/szip-2.1/include.o:
>>>>> and then make should work.
>>>>>
>>>>> The line in the Makefile.Depends is a result of this line in your
>>>>> Makefile.h:
>>>>>  HDF5_PATH = /usr/local/hdf5/hdf5-1.8.1:/usr/local/szip-2.1
>>>>>
>>>>> The setup_depends.py utility (which gets invoked automatically  
>>>>> from
>>>>> make)
>>>>> tries to analyze the command line flags used for invoking the  
>>>>> Fortran
>>>>> compiler, but it doesn't do a good job of it in this case;
>>>>> apparently it doesn't expect that any command line arguments,
>>>>> like -I /usr/local/hdf5/hdf5-1.8.1:/usr/local/szip-2.1/include,
>>>>> contain colons.
>>>>>
>>>>> I suppose the setup_depends.py should be fixed.
>>>>>
>>>>>> In flash2.5 I could not feed szip using a different way than  
>>>>>> this. If
>>>>>> this is the problem how should I do it for flash3.0 or 3.1? I  
>>>>>> have
>>>>>> also attached the Makefile.h for my machine.
>>>>>
>>>>> If you just need to pass
>>>>>  -I/usr/local/szip-2.1/include
>>>>> to the compiler invocations (and/or add something like
>>>>>  -L/usr/local/szip-2.1/lib
>>>>> for the linking step?), then you should modify your Makefile.h  
>>>>> so that
>>>>>
>>>>> 1) you have
>>>>>  HDF5_PATH = /usr/local/hdf5/hdf5-1.8.1
>>>>> 2) add -I/usr/local/szip-2.1/include explicitly in the line  
>>>>> that defines
>>>>>  CFLAGS_HDF5
>>>>> 3) add -L/usr/local/szip-2.1/lib explicitly in the line that  
>>>>> defines
>>>>>  LIB_HDF5 (if needed).
>>>>>
>>>>> Hope this helps,
>>>>>
>>>>> Klaus
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Beatrice Perret
>>>> Department of Physics
>>>> Arizona State University
>>>> P.O. Box 871504
>>>> Tempe, AZ 85287-1504
>>>>
>>>
>>>
>>>
>>> --
>>> Beatrice Perret
>>> Department of Physics
>>> Arizona State University
>>> P.O. Box 871504
>>> Tempe, AZ 85287-1504
>>>
>>>
>>>
>>> --
>>> Beatrice Perret
>>> Department of Physics
>>> Arizona State University
>>> P.O. Box 871504
>>> Tempe, AZ 85287-1504
>>
>>
>
>
>
> -- 
> Beatrice Perret
> Department of Physics
> Arizona State University
> P.O. Box 871504
> Tempe, AZ 85287-1504



From brockp at umich.edu  Thu Oct 23 09:02:39 2008
From: brockp at umich.edu (Brock Palen)
Date: Thu, 23 Oct 2008 10:02:39 -0400
Subject: [FLASH-USERS] hdf5_parallel performance
Message-ID: <7F8152E3-A95A-487E-9B41-8B86BF7171D3@umich.edu>

We are doing our firsts tests of using parallel hdf5 for flash2.  The  
backing filesystem is lustre.

Raw performance to lustre from 10 hosts using MPI_File_write() is  
about 650MB/s.

Looks like writing plot files from 40 hosts is only about 40MB/s  no  
matter the stripe count I use.

Our plot files are around 1.5GB.
Is there any insight into tuning?  writing takes 30 seconds which is  
much longer than we would like it to be for such a small file.


Brock Palen
www.umich.edu/~brockp
Center for Advanced Computing
brockp at umich.edu
(734)936-1985





From tplewa at fsu.edu  Mon Oct 27 18:56:01 2008
From: tplewa at fsu.edu (Tomasz Plewa)
Date: Mon, 27 Oct 2008 19:56:01 -0400
Subject: [FLASH-USERS] FLASH3.1 Orszag-Tang (any MHD setups?)
Message-ID: <49065511.4000000@fsu.edu>

Hello -

I am having a trouble configuring the Orszag-Tang test problem, or 
essentially any MHD test case.

I use

setup -auto -2d magnetoHD/OrszagTang

and code crashes producing the following output. This with flash.par 
supplied with this problem. I have tried BrioWu with identical outcome.

Any suggestions?

Thanks -

Tomek
--

 RuntimeParameters_read:  ignoring unknown parameter "order"...
 RuntimeParameters_read:  ignoring unknown parameter "slopeLimiter"...
 RuntimeParameters_read:  ignoring unknown parameter "LimitedSlopeBeta"...
 RuntimeParameters_read:  ignoring unknown parameter "charLimiting"...
 RuntimeParameters_read:  ignoring unknown parameter "E_modification"...
 RuntimeParameters_read:  ignoring unknown parameter "energyFix"...
 RuntimeParameters_read:  ignoring unknown parameter "RiemannSolver"...
 RuntimeParameters_read:  ignoring unknown parameter "CTU"...
 RuntimeParameters_read:  ignoring unknown parameter "ForceHydroLimit"...
 RuntimeParameters_read:  ignoring unknown parameter "prolMethod"...
 RuntimeParameters_read:  ignoring unknown parameter "iGridSize"...
 RuntimeParameters_read:  ignoring unknown parameter "jGridSize"...
 RuntimeParameters_read:  ignoring unknown parameter "iProcs"...
 RuntimeParameters_read:  ignoring unknown parameter "jProcs"...
 RuntimeParameters_read:  ignoring unknown parameter "kProcs"...
 Grid_init: Monotonic grid interpolation requires at least 4 layers of 
guard cells.
  However, NGUARD is only            2
  Maybe you want to setup with '-gridinterpolation=native',
  or make sure that NGUARD is set correctly in Config file.

 Driver_abort called. See log file for details.
 Error message is Please setup with '-gridinterpolation=native', or 
change NGUARD.
 Calling MPI_Abort() for immediate shutdown!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: tplewa.vcf
Type: text/x-vcard
Size: 296 bytes
Desc: not available
Url : http://flash.uchicago.edu/pipermail/flash-users/attachments/20081027/e213a3bd/attachment.vcf 

From dongwook at flash.uchicago.edu  Mon Oct 27 20:02:31 2008
From: dongwook at flash.uchicago.edu (dongwook at flash.uchicago.edu)
Date: Mon, 27 Oct 2008 20:02:31 -0500 (CDT)
Subject: [FLASH-USERS] FLASH3.1 Orszag-Tang (any MHD setups?)
In-Reply-To: <49065511.4000000@fsu.edu>
References: <49065511.4000000@fsu.edu>
Message-ID: <63790.68.72.104.84.1225155751.squirrel@flash.uchicago.edu>

Hi Tomek,

Please include either "+8wave" or "+usm" in your setup in order to
choose your MHD solver for your simulation.

In both FLASH3 and FLASH3.1, there are two MHD solvers available
for a given MHD simulation.

A default one is the operator splitting 8-wave solver
which has been imported from FLASH2, and a new one is the
operator unsplit staggered mesh (USM) solver,
which I have developed and implemented for FLASH3.

Note that the official release of FLASH3.1 only include
1D and 2D implementations of the USM solver and a full
3D is available by sending me an email request.

The abort you reported was because the 8wave solver needs only
two layers of guard cells, while the USM solver needs four of them.

The details of two solvers have been described in the FLASH user's
guide and you can find it at:

http://flash.uchicago.edu/website/codesupport/flash3_ug_3p1/

Please go to section 13.4 to see the MHD part.

If you need more information on the USM solver, please have a
look at my paper:

doi:10.1016/j.jcp.2008.08.026


Regards,
Dongwook



> Hello -
>
> I am having a trouble configuring the Orszag-Tang test problem, or
> essentially any MHD test case.
>
> I use
>
> setup -auto -2d magnetoHD/OrszagTang
>
> and code crashes producing the following output. This with flash.par
> supplied with this problem. I have tried BrioWu with identical outcome.
>
> Any suggestions?
>
> Thanks -
>
> Tomek
> --
>
>  RuntimeParameters_read:  ignoring unknown parameter "order"...
>  RuntimeParameters_read:  ignoring unknown parameter "slopeLimiter"...
>  RuntimeParameters_read:  ignoring unknown parameter "LimitedSlopeBeta"...
>  RuntimeParameters_read:  ignoring unknown parameter "charLimiting"...
>  RuntimeParameters_read:  ignoring unknown parameter "E_modification"...
>  RuntimeParameters_read:  ignoring unknown parameter "energyFix"...
>  RuntimeParameters_read:  ignoring unknown parameter "RiemannSolver"...
>  RuntimeParameters_read:  ignoring unknown parameter "CTU"...
>  RuntimeParameters_read:  ignoring unknown parameter "ForceHydroLimit"...
>  RuntimeParameters_read:  ignoring unknown parameter "prolMethod"...
>  RuntimeParameters_read:  ignoring unknown parameter "iGridSize"...
>  RuntimeParameters_read:  ignoring unknown parameter "jGridSize"...
>  RuntimeParameters_read:  ignoring unknown parameter "iProcs"...
>  RuntimeParameters_read:  ignoring unknown parameter "jProcs"...
>  RuntimeParameters_read:  ignoring unknown parameter "kProcs"...
>  Grid_init: Monotonic grid interpolation requires at least 4 layers of
> guard cells.
>   However, NGUARD is only            2
>   Maybe you want to setup with '-gridinterpolation=native',
>   or make sure that NGUARD is set correctly in Config file.
>
>  Driver_abort called. See log file for details.
>  Error message is Please setup with '-gridinterpolation=native', or
> change NGUARD.
>  Calling MPI_Abort() for immediate shutdown!
>
>



From dongwook at flash.uchicago.edu  Mon Oct 27 20:09:23 2008
From: dongwook at flash.uchicago.edu (dongwook at flash.uchicago.edu)
Date: Mon, 27 Oct 2008 20:09:23 -0500 (CDT)
Subject: [FLASH-USERS] FLASH3.1 Orszag-Tang (any MHD setups?)
In-Reply-To: <49065511.4000000@fsu.edu>
References: <49065511.4000000@fsu.edu>
Message-ID: <63926.68.72.104.84.1225156163.squirrel@flash.uchicago.edu>

Hi Tomek,

Please use a link

http://dx.doi.org/10.1016/j.jcp.2008.08.026

to get my unsplit staggered mesh paper.
The link I gave you in my previous email doesn't seem to work.

Regards,
Dongwook



> Hello -
>
> I am having a trouble configuring the Orszag-Tang test problem, or
> essentially any MHD test case.
>
> I use
>
> setup -auto -2d magnetoHD/OrszagTang
>
> and code crashes producing the following output. This with flash.par
> supplied with this problem. I have tried BrioWu with identical outcome.
>
> Any suggestions?
>
> Thanks -
>
> Tomek
> --
>
>  RuntimeParameters_read:  ignoring unknown parameter "order"...
>  RuntimeParameters_read:  ignoring unknown parameter "slopeLimiter"...
>  RuntimeParameters_read:  ignoring unknown parameter "LimitedSlopeBeta"...
>  RuntimeParameters_read:  ignoring unknown parameter "charLimiting"...
>  RuntimeParameters_read:  ignoring unknown parameter "E_modification"...
>  RuntimeParameters_read:  ignoring unknown parameter "energyFix"...
>  RuntimeParameters_read:  ignoring unknown parameter "RiemannSolver"...
>  RuntimeParameters_read:  ignoring unknown parameter "CTU"...
>  RuntimeParameters_read:  ignoring unknown parameter "ForceHydroLimit"...
>  RuntimeParameters_read:  ignoring unknown parameter "prolMethod"...
>  RuntimeParameters_read:  ignoring unknown parameter "iGridSize"...
>  RuntimeParameters_read:  ignoring unknown parameter "jGridSize"...
>  RuntimeParameters_read:  ignoring unknown parameter "iProcs"...
>  RuntimeParameters_read:  ignoring unknown parameter "jProcs"...
>  RuntimeParameters_read:  ignoring unknown parameter "kProcs"...
>  Grid_init: Monotonic grid interpolation requires at least 4 layers of
> guard cells.
>   However, NGUARD is only            2
>   Maybe you want to setup with '-gridinterpolation=native',
>   or make sure that NGUARD is set correctly in Config file.
>
>  Driver_abort called. See log file for details.
>  Error message is Please setup with '-gridinterpolation=native', or
> change NGUARD.
>  Calling MPI_Abort() for immediate shutdown!
>
>



From tplewa at fsu.edu  Mon Oct 27 20:26:07 2008
From: tplewa at fsu.edu (Tomasz Plewa)
Date: Mon, 27 Oct 2008 21:26:07 -0400
Subject: [FLASH-USERS] FLASH3.1 Orszag-Tang (any MHD setups?)
In-Reply-To: <63790.68.72.104.84.1225155751.squirrel@flash.uchicago.edu>
References: <49065511.4000000@fsu.edu>
	<63790.68.72.104.84.1225155751.squirrel@flash.uchicago.edu>
Message-ID: <49066A2F.3060900@fsu.edu>

Dear Dongwook -

Thanks for explaining, and congratulations on publishing your paper!

Section 22.2 does not list additional options so I expected MHD setups 
supplied with the code working straight out-of-the-box with provided 
defaults (say -auto -2d).

Best -

Tomek
--
dongwook at flash.uchicago.edu wrote:
> Hi Tomek,
>
> Please include either "+8wave" or "+usm" in your setup in order to
> choose your MHD solver for your simulation.
>
> In both FLASH3 and FLASH3.1, there are two MHD solvers available
> for a given MHD simulation.
>
> A default one is the operator splitting 8-wave solver
> which has been imported from FLASH2, and a new one is the
> operator unsplit staggered mesh (USM) solver,
> which I have developed and implemented for FLASH3.
>
> Note that the official release of FLASH3.1 only include
> 1D and 2D implementations of the USM solver and a full
> 3D is available by sending me an email request.
>
> The abort you reported was because the 8wave solver needs only
> two layers of guard cells, while the USM solver needs four of them.
>
> The details of two solvers have been described in the FLASH user's
> guide and you can find it at:
>
> http://flash.uchicago.edu/website/codesupport/flash3_ug_3p1/
>
> Please go to section 13.4 to see the MHD part.
>
> If you need more information on the USM solver, please have a
> look at my paper:
>
> doi:10.1016/j.jcp.2008.08.026
>
>
> Regards,
> Dongwook
>
>
>
>   
>> Hello -
>>
>> I am having a trouble configuring the Orszag-Tang test problem, or
>> essentially any MHD test case.
>>
>> I use
>>
>> setup -auto -2d magnetoHD/OrszagTang
>>
>> and code crashes producing the following output. This with flash.par
>> supplied with this problem. I have tried BrioWu with identical outcome.
>>
>> Any suggestions?
>>
>> Thanks -
>>
>> Tomek
>> --
>>
>>  RuntimeParameters_read:  ignoring unknown parameter "order"...
>>  RuntimeParameters_read:  ignoring unknown parameter "slopeLimiter"...
>>  RuntimeParameters_read:  ignoring unknown parameter "LimitedSlopeBeta"...
>>  RuntimeParameters_read:  ignoring unknown parameter "charLimiting"...
>>  RuntimeParameters_read:  ignoring unknown parameter "E_modification"...
>>  RuntimeParameters_read:  ignoring unknown parameter "energyFix"...
>>  RuntimeParameters_read:  ignoring unknown parameter "RiemannSolver"...
>>  RuntimeParameters_read:  ignoring unknown parameter "CTU"...
>>  RuntimeParameters_read:  ignoring unknown parameter "ForceHydroLimit"...
>>  RuntimeParameters_read:  ignoring unknown parameter "prolMethod"...
>>  RuntimeParameters_read:  ignoring unknown parameter "iGridSize"...
>>  RuntimeParameters_read:  ignoring unknown parameter "jGridSize"...
>>  RuntimeParameters_read:  ignoring unknown parameter "iProcs"...
>>  RuntimeParameters_read:  ignoring unknown parameter "jProcs"...
>>  RuntimeParameters_read:  ignoring unknown parameter "kProcs"...
>>  Grid_init: Monotonic grid interpolation requires at least 4 layers of
>> guard cells.
>>   However, NGUARD is only            2
>>   Maybe you want to setup with '-gridinterpolation=native',
>>   or make sure that NGUARD is set correctly in Config file.
>>
>>  Driver_abort called. See log file for details.
>>  Error message is Please setup with '-gridinterpolation=native', or
>> change NGUARD.
>>  Calling MPI_Abort() for immediate shutdown!
>>
>>
>>     
>
>   
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tplewa.vcf
Type: text/x-vcard
Size: 296 bytes
Desc: not available
Url : http://flash.uchicago.edu/pipermail/flash-users/attachments/20081027/909742b5/attachment.vcf 

From jfg at ucolick.org  Tue Oct 28 10:05:57 2008
From: jfg at ucolick.org (James Guillochon)
Date: Tue, 28 Oct 2008 08:05:57 -0700
Subject: [FLASH-USERS] Filling Guard Cells in Burn
Message-ID: <49072A55.2070507@ucolick.org>

Hi guys,

So I'm using the nuclearBurn unit (FLASH 3.0), and the 
Grid_fillGuardCells routine at the top of Burn.F90 seems to be taking an 
inordinate amount of time to run. My simulation has sporadic burning and 
thus does not need the network to run at every time step, but the 
fillGuardCells routine is taking most of the processing time even with T 
<< nuclearTempMin!

The question is: Do I have to fill the guard cells if the temperature 
criteria for burning isn't met? Is there some reason the fillGuardCells 
routine is taking so long in this context?

Thanks!

-- 

James Guillochon
Department of Astronomy & Astrophysics
University of California, Santa Cruz
jfg at ucolick.org


From klaus at flash.uchicago.edu  Tue Oct 28 11:33:48 2008
From: klaus at flash.uchicago.edu (Klaus Weide)
Date: Tue, 28 Oct 2008 11:33:48 -0500 (CDT)
Subject: [FLASH-USERS] Filling Guard Cells in Burn
In-Reply-To: <49072A55.2070507@ucolick.org>
References: <49072A55.2070507@ucolick.org>
Message-ID: <Pine.LNX.4.64.0810281048370.15609@flash.uchicago.edu>

On Tue, 28 Oct 2008, James Guillochon wrote:
> So I'm using the nuclearBurn unit (FLASH 3.0), and the Grid_fillGuardCells 
> routine at the top of Burn.F90 seems to be taking an inordinate amount of 
> time to run. My simulation has sporadic burning and thus does not need the 
> network to run at every time step, but the fillGuardCells routine is taking 
> most of the processing time even with T << nuclearTempMin!

James,

First of all, I am surprised this takes an "inordinate amount of time".
I would expect that the Grid_fillGuardCells calls in other places, 
predominantly in Hydro, use more time, just because they would be
called more often (at least when NDIM > 1).  I am thinking of a "normal"
FLASH simulation that uses Hydro, and Burn, and probably some other 
physics units.

If you just mean that the Grid_fillGuardCells in Burn dominates the total 
time spent in Burn - that may well be, but see below.

> The question is: Do I have to fill the guard cells if the temperature 
> criteria for burning isn't met? Is there some reason the fillGuardCells 
> routine is taking so long in this context?

I am assuming you are referring to this source file:
    source/physics/sourceTerms/Burn/BurnMain/nuclearBurn/Burn.F90 ,
let me know if I'm wrong!

There has been a code change in this file from FLASH 3.0 to 3.1,
associated with this comment:

=========================================================================================================
Filename: trunk/source/physics/sourceTerms/Burn/BurnMain/nuclearBurn/Burn.F90
Revision 8763
Modified Fri Mar 21 13:28:56 2008 CDT (7 months, 1 week ago) by townsley
File length: 9383 byte(s)
Diff to previous 7876

[...]
Also limited nuclear Burn calculations to only interior cells,
no need to do the guard cells.
=========================================================================================================

Here is the diff:

=========================================================================================================
*** trunk/source/physics/sourceTerms/Burn/BurnMain/nuclearBurn/Burn.F90	2008/01/07 16:23:52	7876
--- trunk/source/physics/sourceTerms/Burn/BurnMain/nuclearBurn/Burn.F90	2008/03/21 18:28:56	8763
***************
*** 150,158 ****


        ! now guaranteed that tmp, rho, etc. exist
!      do k = blkLimitsGC(LOW,KAXIS), blkLimitsGC(HIGH,KAXIS)
!         do j = blkLimitsGC(LOW,JAXIS), blkLimitsGC(HIGH,JAXIS)
!            do i = blkLimitsGC(LOW,IAXIS), blkLimitsGC(HIGH,IAXIS)
                 okBurnTemp = .FALSE.
                 okBurnDens = .FALSE.
                 okBurnShock = .FALSE.
--- 150,158 ----


        ! now guaranteed that tmp, rho, etc. exist
!      do k = blkLimits(LOW,KAXIS), blkLimits(HIGH,KAXIS)
!         do j = blkLimits(LOW,JAXIS), blkLimits(HIGH,JAXIS)
!            do i = blkLimits(LOW,IAXIS), blkLimits(HIGH,IAXIS)
                 okBurnTemp = .FALSE.
                 okBurnDens = .FALSE.
                 okBurnShock = .FALSE.
=========================================================================================================

(There were also changes in that update related to enabling Burn_computeDt. If you use
Burn_computeDt, it probably should have the same kind of blkLimitsGC -> blkLimits change.)

I believe that with the FLASH 3.1 version, the only reason for having a Grid_fillGuardCells call
at the top of Burn.F90 is to provide valid data for Hydro_detectShock.  (That's why Grid_fillGuardCells
is only called 'if (.NOT. bn_useShockBurn)').

If you look at the code of Hydro_detectShock.F90, you will find that it requires only 
a limited number of guard cell layers (1 or 2?) for its stencil, and it refers only to
a small number of UNK variables (VEL{X,Y,Z}_VAR and PRES_VAR).  You could therefore
try to speed up the Grid_fillGuardCells calls somewhat by limiting the number of
cell layers and/or variables that are exchanged - see Grid_fillGuardCells.F90 for
the various OPTIONAL arguments that may apply.  To restrict the set of variables
that are exchanged, also make sure the runtime parameter
   enableMaskedGcFill
is TRUE.


There is currently no way to limit guard cell exchanges only to some 
blocks or processors that may need them - it's an all-or-nothing thing in 
that way.  But if you know of some criteria to determine globally that in 
a given invocation of Burn, there is no need to call Hydro_detectShock on 
ANY block in the simulation (for example, because you can determine 
positively that the Burn variables okBurnTemp .AND. okBurnDens will be 
FALSE in all cells in all leaf blocks) - then you can of course skip the 
call in that invocation of Burn.



Klaus


From jfg at ucolick.org  Tue Oct 28 14:12:53 2008
From: jfg at ucolick.org (James Guillochon)
Date: Tue, 28 Oct 2008 12:12:53 -0700
Subject: [FLASH-USERS] Filling Guard Cells in Burn
In-Reply-To: <Pine.LNX.4.64.0810281048370.15609@flash.uchicago.edu>
References: <49072A55.2070507@ucolick.org>
	<Pine.LNX.4.64.0810281048370.15609@flash.uchicago.edu>
Message-ID: <49076435.6010407@ucolick.org>

I upgraded my Burn unit to 3.1 (and SimulationComposition), and things 
are running much faster now (10 times faster)! Considering 
fillGuardCells is still being called, I guess the issue must have been 
unrelated to my initial guess...

-- 
James Guillochon
Department of Astronomy & Astrophysics
University of California, Santa Cruz
jfg at ucolick.org


Klaus Weide wrote:
> On Tue, 28 Oct 2008, James Guillochon wrote:
>> So I'm using the nuclearBurn unit (FLASH 3.0), and the 
>> Grid_fillGuardCells routine at the top of Burn.F90 seems to be taking 
>> an inordinate amount of time to run. My simulation has sporadic 
>> burning and thus does not need the network to run at every time step, 
>> but the fillGuardCells routine is taking most of the processing time 
>> even with T << nuclearTempMin!
> 
> James,
> 
> First of all, I am surprised this takes an "inordinate amount of time".
> I would expect that the Grid_fillGuardCells calls in other places, 
> predominantly in Hydro, use more time, just because they would be
> called more often (at least when NDIM > 1).  I am thinking of a "normal"
> FLASH simulation that uses Hydro, and Burn, and probably some other 
> physics units.
> 
> If you just mean that the Grid_fillGuardCells in Burn dominates the 
> total time spent in Burn - that may well be, but see below.
> 
>> The question is: Do I have to fill the guard cells if the temperature 
>> criteria for burning isn't met? Is there some reason the 
>> fillGuardCells routine is taking so long in this context?
> 
> I am assuming you are referring to this source file:
>    source/physics/sourceTerms/Burn/BurnMain/nuclearBurn/Burn.F90 ,
> let me know if I'm wrong!
> 
> There has been a code change in this file from FLASH 3.0 to 3.1,
> associated with this comment:
> 
> ========================================================================================================= 
> 
> Filename: 
> trunk/source/physics/sourceTerms/Burn/BurnMain/nuclearBurn/Burn.F90
> Revision 8763
> Modified Fri Mar 21 13:28:56 2008 CDT (7 months, 1 week ago) by townsley
> File length: 9383 byte(s)
> Diff to previous 7876
> 
> [...]
> Also limited nuclear Burn calculations to only interior cells,
> no need to do the guard cells.
> ========================================================================================================= 
> 
> 
> Here is the diff:
> 
> ========================================================================================================= 
> 
> *** 
> trunk/source/physics/sourceTerms/Burn/BurnMain/nuclearBurn/Burn.F90    
> 2008/01/07 16:23:52    7876
> --- 
> trunk/source/physics/sourceTerms/Burn/BurnMain/nuclearBurn/Burn.F90    
> 2008/03/21 18:28:56    8763
> ***************
> *** 150,158 ****
> 
> 
>        ! now guaranteed that tmp, rho, etc. exist
> !      do k = blkLimitsGC(LOW,KAXIS), blkLimitsGC(HIGH,KAXIS)
> !         do j = blkLimitsGC(LOW,JAXIS), blkLimitsGC(HIGH,JAXIS)
> !            do i = blkLimitsGC(LOW,IAXIS), blkLimitsGC(HIGH,IAXIS)
>                 okBurnTemp = .FALSE.
>                 okBurnDens = .FALSE.
>                 okBurnShock = .FALSE.
> --- 150,158 ----
> 
> 
>        ! now guaranteed that tmp, rho, etc. exist
> !      do k = blkLimits(LOW,KAXIS), blkLimits(HIGH,KAXIS)
> !         do j = blkLimits(LOW,JAXIS), blkLimits(HIGH,JAXIS)
> !            do i = blkLimits(LOW,IAXIS), blkLimits(HIGH,IAXIS)
>                 okBurnTemp = .FALSE.
>                 okBurnDens = .FALSE.
>                 okBurnShock = .FALSE.
> ========================================================================================================= 
> 
> 
> (There were also changes in that update related to enabling 
> Burn_computeDt. If you use
> Burn_computeDt, it probably should have the same kind of blkLimitsGC -> 
> blkLimits change.)
> 
> I believe that with the FLASH 3.1 version, the only reason for having a 
> Grid_fillGuardCells call
> at the top of Burn.F90 is to provide valid data for Hydro_detectShock.  
> (That's why Grid_fillGuardCells
> is only called 'if (.NOT. bn_useShockBurn)').
> 
> If you look at the code of Hydro_detectShock.F90, you will find that it 
> requires only a limited number of guard cell layers (1 or 2?) for its 
> stencil, and it refers only to
> a small number of UNK variables (VEL{X,Y,Z}_VAR and PRES_VAR).  You 
> could therefore
> try to speed up the Grid_fillGuardCells calls somewhat by limiting the 
> number of
> cell layers and/or variables that are exchanged - see 
> Grid_fillGuardCells.F90 for
> the various OPTIONAL arguments that may apply.  To restrict the set of 
> variables
> that are exchanged, also make sure the runtime parameter
>   enableMaskedGcFill
> is TRUE.
> 
> 
> There is currently no way to limit guard cell exchanges only to some 
> blocks or processors that may need them - it's an all-or-nothing thing 
> in that way.  But if you know of some criteria to determine globally 
> that in a given invocation of Burn, there is no need to call 
> Hydro_detectShock on ANY block in the simulation (for example, because 
> you can determine positively that the Burn variables okBurnTemp .AND. 
> okBurnDens will be FALSE in all cells in all leaf blocks) - then you can 
> of course skip the call in that invocation of Burn.
> 
> 
> 
> Klaus
> 
> !DSPAM:10135,49073eed148013225631196!
> 


From josef.stoeckl at uibk.ac.at  Wed Oct 29 14:00:01 2008
From: josef.stoeckl at uibk.ac.at (=?ISO-8859-1?Q?Josef_St=F6ckl?=)
Date: Wed, 29 Oct 2008 20:00:01 +0100
Subject: [FLASH-USERS] Strange abort condition with Particles
Message-ID: <4908B2B1.5040905@uibk.ac.at>

Hello,

I'v migrated a simulation from FLASH 3.0 which uses active particles 
with CIC mapping. I've changed the Config file to reflect the changes in 
the particle unit (PARTICLETYPE active INITMETHOD CUSTOM MAPMETHOD 
WEIGHTED) and everything compiles quite nicely.

At runtime however after reading in the particles files (256^3 
particles), I get some "Error, we should not be here." as well as the 
following abort message: "Shouldn't be here!".

I've found this message to originate from gr_ptFindNegh.F90 (line 487) 
of the Grid/GridParticles/GridParticlesMapToMesh/Paramesh unit. I'm a 
bit puzzled why this seems to happen, especially since commenting out 
the abort and restoring the old gr_ptSearchBlk behaviour also leads to 
other errors ("[gr_ptMoveMappedData]: timesInLoop >= gr_numProcs" and 
"[gr_ptDumpState]: Metadata loop will not exit cleanly!" in the log).

I had another look at the Pancake example and checked if there were some 
other differences in those routines compared to release 3.0, but didn't 
find anything. Can anyone of you tell me or give me a clue as to why 
this is happening?

Thanks in advance and best regards,
Josef

PS: I included my simulation's Config file.

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Config
Url: http://flash.uchicago.edu/pipermail/flash-users/attachments/20081029/148afe1e/attachment.pl 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: josef_stoeckl.vcf
Type: text/x-vcard
Size: 341 bytes
Desc: not available
Url : http://flash.uchicago.edu/pipermail/flash-users/attachments/20081029/148afe1e/attachment.vcf 

From cdaley at flash.uchicago.edu  Wed Oct 29 15:55:17 2008
From: cdaley at flash.uchicago.edu (Chris Daley)
Date: Wed, 29 Oct 2008 15:55:17 -0500
Subject: [FLASH-USERS] Strange abort condition with Particles
In-Reply-To: <4908BA2B.9080209@flash.uchicago.edu>
References: <4908B2B1.5040905@uibk.ac.at> <4908BA2B.9080209@flash.uchicago.edu>
Message-ID: <4908CDB5.1050203@flash.uchicago.edu>

Hi Josef,

I'm interested to know how many processors you are using, and the
dimensionality of your simulation?  Someone at the FLASH center
actually reported the exact same problem this morning.  We are going
to look at the problem tomorrow when he returns.  In his case, the
problem occurred at a large scale (4096 processors).  If you have a
smaller scale problem that reproduces the problem then that would be
very useful for me.

I'm very surprised about the original error message you receive.  This
abort is triggered from an assertion about neighboring processor IDs.
The actual value is obtained from a PARAMESH data-structure, so
perhaps in some situation I'm accessing the incorrect index in this
structure?

I'll keep you updated.

Chris


Lynn Reid wrote:
> Hi Josef:
>
> Thanks for reporting the problem.  Could you please email me back your 
> setup line?
> e.g. prompt> ./setup SkiTeam -auto -blah blah blah
> And also your run configuration
> prompt> mpirun -np ? SkiTeam
>
> We'll take a look at figuring out what's going wrong.  As you may have 
> noticed, there was considerable change in the Particles routines from 
> FLASH3.0 to FLASH3.1.
>
> Best wishes,
> Lynn
>
> Josef St?ckl wrote:
>> Hello,
>>
>> I'v migrated a simulation from FLASH 3.0 which uses active particles 
>> with CIC mapping. I've changed the Config file to reflect the changes 
>> in the particle unit (PARTICLETYPE active INITMETHOD CUSTOM MAPMETHOD 
>> WEIGHTED) and everything compiles quite nicely.
>>
>> At runtime however after reading in the particles files (256^3 
>> particles), I get some "Error, we should not be here." as well as the 
>> following abort message: "Shouldn't be here!".
>>
>> I've found this message to originate from gr_ptFindNegh.F90 (line 
>> 487) of the Grid/GridParticles/GridParticlesMapToMesh/Paramesh unit. 
>> I'm a bit puzzled why this seems to happen, especially since 
>> commenting out the abort and restoring the old gr_ptSearchBlk 
>> behaviour also leads to other errors ("[gr_ptMoveMappedData]: 
>> timesInLoop >= gr_numProcs" and "[gr_ptDumpState]: Metadata loop will 
>> not exit cleanly!" in the log).
>>
>> I had another look at the Pancake example and checked if there were 
>> some other differences in those routines compared to release 3.0, but 
>> didn't find anything. Can anyone of you tell me or give me a clue as 
>> to why this is happening?
>>
>> Thanks in advance and best regards,
>> Josef
>>
>> PS: I included my simulation's Config file.
>>
>