Members
This document attempts to answer FLASH related questions not covered in the
User's Guide or the Code paper. Please consult those references in addition
to this FAQ if your question is not answered here.
Table of Contents:
==================
Section 0: Getting Started
Q0.1 Where can I find the latest documentation?
Q0.2 What if my question is not answered by any of the available
documentation?
Q0.3 What is the latest version of FLASH?
Q0.4 What do I need to install, compile, and run FLASH?
Q0.5 Where can I find a list of compilers/platforms that FLASH has
been tested with?
Section 1: Compiling FLASH
Q1.1 When I try to make FLASH, I get the following error:
make: file `Makefile.driver' line 34: Must be a separator (: or ::)
for rules (bu39)
Q1.2 I noticed that FLASH uses the REAL declaration for single
precision. Is there a simple way to make sure the computer
calculates to DOUBLE PRECISION, even though the variables are
defined with REAL?
Q1.3 I am trying to get FLASH to run on my machine, but there is no
appropriate sites directory for it -- what do I do?
Q1.4 When I make FLASH, lots of compilation lines are output, but no
object (.o) files are produced in object/ -- what's up?
Q1.5 I'm too lazy to type that long setup line -- how do you get tab
completion working with setup?
Section 2: General FLASH Questions
Q2.1 What exactly is a "top level block"?
Q2.2 How do I determine the number of zones a corresponding uniform
grid calculation would have, with the same finest spatial
resolution?
Q2.3 Do you have a rule-of-thumb for determining the approximate memory
needed for a problem to run in a batch queue?
Q2.4 In the runtime parameters, what is meant by "cutoff values", for
example, small, smlrho, smallp/e/t/u/x ?
Q2.5 How do I set the boundary conditions with FLASH? Is this a
parameter in the flash.par file?
Q2.6 How can I setup FLASH to run a problem with a uniform grid?
Q2.7 What does the version number (i.e. FLASH 2.0.20001129) mean?
Q2.8 What coordinate systems does FLASH support?
Q2.9 How can I get FLASH to refine a particular region of the grid?
Section 3: Runtime Errors
Q3.1 The detonation problem dies when after the first timestep, with
the error message: matrix is structurally singular, rank = 1,
when running on an SGI
Q3.2 I get the an mmap error when running a large job (>~ 32
processors) on an SGI
Q3.3 FLASH runs for a while but all of a sudden it stops, without
printing any errors to stdout -- what's going on?
Q3.4 I can compile FLASH with HDF5 fine, but when I run I get an
error -- ``error while loading shared libraries:
libhdf5.so.0''. How do I get HDF5 output to work?
Q3.5 FLASH segmentation faults on an IBM when running on multiple
processors, what's up?
Q3.6 When I run FLASH on an IBM machine using the AIX compilers, I
get far more blocks than I do on other platforms -- how do
I fix this?
Section 4: Extending FLASH
Q4.1 How do I create a setup that reads in a 1-dimensional model and
maps it onto the FLASH domain?
Q4.2 How do I add a new problem to FLASH?
Section 5: Physics Modules
Q5.1 How do I run a problem that includes thermal diffusion?
Q5.2 What's the difference between helm_table.dat and
helm_table.bdat? Why can't I find helm_table.bdat anywhere
in the source tree?
Section 6: I/O Questions
Q6.1 What is the difference between the output files:
name_hdf_plt_cnt_0000
name_hdf_chk_0000?
Q6.2 I am submitting a FLASH job in a queue with an 8 hour run limit,
and I want to ensure that I generate a checkpoint file before
the job is killed -- is there an easy way to do this?
Q6.3 How do I get FLASH to use HDF 5 instead of HDF 4?
Q6.4 What versions of the HDF libraries has FLASH been tested with?
Q6.5 How do I set which variables are stored in a plotfile?
Section 7: Plotting Routines
Q7.1 What version of IDL is required to run the fidlr routines?
Q7.2 I get lots of errors like:
fendSuffix = cw_field(suf_base, title = 'to', value = ' ', $
% Syntax error.
At: ~/FLASH2.2/tools/fidlr2/xflash.pro, Line 1239
when I run xflash off the IDL command line. What gives?
Q7.3 What other packages have been used to look at FLASH data?
---------------------------
Section 0: Getting Started
==========================
Q0.1 Where can I find the latest documentation?
The user's guide is posted on the Flash Center website
(http://flash.uchicago.edu/flashcode/doc/).
The latest version of the FLASH Code FAQ is posted at
(http://flash.uchicago.edu/~zingale/FLASH_FAQ/).
In addition to these documents, there are a growing number of
HOWTOs stored in the FLASH directory structure under
docs/HOWTO/. These usually deal with getting FLASH to run on
specific machines/architectures or using performance analysis
tools with FLASH. We welcome any contributions to the HOWTO
library.
Q0.2 What if my question is not answered by any of the available
documentation?
There are two e-mail lists available for FLASH questions.
The first, flash-bugs@flash.uchicago.edu, is to report bugs
or ask questions regarding the operation of FLASH. This list
will broadcast your message to all the FLASH developers.
The second mailing list is flash-users@flash.uchicago.edu.
This mailing list is intended for discussions with other
FLASH users. This is the appropriate forum for general
topics regarding FLASH that other users may be interested in
hearing about.
Q0.3 What is the latest version of FLASH?
FLASH 2.2 is the current release version of the code.
Q0.4 What do I need to install, compile, and run FLASH?
The current requirements for FLASH 2.X are:
-- Fortran 90 compiler
-- C compiler
-- an MPI implementation (e.g. MPICH)
-- python 1.52 or greater (for setup)
-- HDF4/5 for I/O
-- IDL 5.3 for the included IDL visualization routines
Q0.5 Where can I find a list of compilers/platforms that FLASH has
been tested with?
The most up-to-date information on platforms and compilers is
contained in the file RELEASE-NOTES in the FLASH2.2/ root
directory.
Section 1: Compiling FLASH
==========================
Q1.1 When I try to make FLASH, I get the following error:
make: file `Makefile.driver' line 34: Must be a separator (: or ::)
for rules (bu39)
FLASH requires the use of GNU make (usually called gmake on a
system) to build the code.
Q1.2 I noticed that FLASH uses the REAL declaration for single
precision. Is there a simple way to make sure the computer
calculates to DOUBLE PRECISION, even though the variables are
defined with REAL?
Although the variables are all declared as real instead of
double precision (of real*8) in the code, and constants are
written as 1.e30 instead of 1.d30, the Makefiles for the
different platforms use compiler switches to promote the
reals to double precision. This is necessary since on some
platforms (Cray T3E), double precision is 16-byte precision.
An included utility, precision_test, can be used to determine
if your compiler supports promotion. This can be built with
the master Makefile in the object/ directory
Q1.3 I am trying to get FLASH to run on my machine, but there is no
appropriate sites directory for it -- what do I do?
setup uses the hostname command to determine which sites
directory to use. If you host is not found, it looks for
a Prototypes directory matching your architecture (for
example Prototypes/Linux). A Makefile.h file contained
in one of these directories lists the compilers to use,
compilation flags, and library paths.
To create a custom Makefile.h for your site, create a
directory under source/sites that is the name returned by
hostname (ex. nan.ucolick.org). In this directory, copy the
Makefile.h from the Prototypes directory that closest matches
your system (the Makefile in sphere.uchicago.edu is usually
the most up-to-date and should be used as a starting point if
no other sites seem appropriate.
The following macros are defined in the Makefile.h
FCOMP -- the name of the Fortran 90 compiler
CCOMP -- the name of the C compiler
CPPCOMP -- the name of the C++ compiler
LINK -- the name of the linker (usually the Fortran
compiler should serve as the linker)
PP -- a flag (if any) that should preceed a
preprocessor directive (typically -D)
FFLAGS_OPT -- the Fortran compilation flags to produce
an optimized executable. These are the
flags used when -auto is given to setup.
FFLAGS_DEBUG -- the Fortran compilation flags to produce
an executable that can be used with a
debugger (e.g. totalview). These flags
are used when -debug is passed to setup.
FFLAGS_TEST -- Fortran compilation flags to produce an
executable suitable for testing. These
usually involve less optimization. These
flags are used when -test is passed to
setup.
CFLAGS_OPT -- the optimized set of compilation flags for
C/C++ code.
CFLAGS_DEBUG -- the debug compilation flags for C/C++ code.
CFLAGS_TEST -- the test compilation flags for C/C++ code.
LFLAGS_OPT -- linker flags used with the _OPT compilation
flags. This usually ends in '-o' to rename
the executable.
LFLAGS_DEBUG -- linker flags used with the _DEBUG compilation.
LFLAGS_TEST -- linker flags used with the _TEST compilation.
LIB_OPT -- libraries to link in with the _OPT compilation.
This should include the MPI library if a MPI
wrapper for the linker was not used (e.g. mpif90).
LIB_DEBUG -- libraries to link in the with the _DEBUG
compilation.
LIB_TEST -- libraries to link in with the _TEST compilation.
LIB_HDF4 -- the necessary link line required to link the
HDF4 library. This will be something of the
form:
-L /path/to/library -lmfhdf -ldf -ljpeg -lz
LIB_HDF5 -- the necessary link line required to link in the
HDF5 library. This will look something like:
-L /path/to/library -lhdf5
Q1.4 When I make FLASH, lots of compilation lines are output, but no
object (.o) files are produced in object/ -- what's up?
Older versions of MPICH do not recognize .F90 as a valid Fortran
file extension in the mpif90 compiler wrapper. All FLASH
Fortran files end in .F90, to signify that they are free-form
and require preprocessing.
To fix this, edit the mpif90 wrapper and add ".F90" to the
if test on the file extension. It should look something like
this:
if [ "$ext" = ".f" -o "$ext" = ".F" -o "$ext" = ".f90" -o \
"$ext" = ".for" -o "$ext" = ".FOR" -o "$ext" = ".F90" ] ; then
This should make mpif90 recognize .F90 files.
Q1.5 I'm too lazy to type that long setup line -- how do you get tab
completion working with setup?
If you use tcsh, add the following to your .{t}cshrc file:
# setup the tab completion for FLASH 2.2
setenv FLASH_HOME /home/username/FLASH2.2
ls -1 ${FLASH_HOME}/setups | awk '{printf("%s ", $1) }' > ~/.flashsetups
set setupFlags = (-verbose -portable -auto -1d -2d -3d \
-maxblocks -site -ostype \
-debug -test -preprocess -report -objdir)
complete setup p/1/"( ` cat ~/.flashsetups ` )"/ p/2-/"(${setupFlags})"/
Section 2: General FLASH Questions
==================================
Q2.1 What exactly is a "top level block"?
A top level block is a block which is at the very top of the
tree structure. All other blocks are children of a top level
block. The default in FLASH is to create a single top level
block when the program is run, and this will be refined as
necessary to create all the children blocks.
If you wish to have more than one top level block, perhaps if
your domain is not square, you can specify the number of top
level blocks through the runtime parameters nblockx, nblocky,
and nblockz. These are used in the routine divide_domain to
setup the initial FLASH grid.
Q2.2 How do I determine the number of zones a corresponding uniform
grid calculation would have, with the same finest spatial
resolution?
When a block refines, it is divide in half in each of the
spatial dimensions. Thus, a parent block creates 2 children
in 1-d, 4 in 2-d, and 8 in 3-d.
The number of zones in each direction if the grid were completely
refined is:
x: nblockx * nxb * 2**(lrefine_max - 1)
y: nblocky * nyb * 2**(lrefine_max - 1)
z: nblockz * nzb * 2**(lrefine_max - 1)
The spatial resolution in the zones with the highest level of
refinement is
x: (xmax - xmin) / (nblockx * nxb * 2**(lrefine_max - 1))
y: (ymax - ymin) / (nblocky * nyb * 2**(lrefine_max - 1))
z: (zmax - zmin) / (nblockz * nzb * 2**(lrefine_max - 1))
Q2.3 Do you have a rule-of-thumb for determining the approximate memory
needed for a problem to run in a batch queue?
The largest amount of memory is taken up by the unk array,
which is allocated as
unk(nvar,2*nguard+nxb,2*nguard+nyb,2*nguard+nzb,maxblocks)
in three dimensions. For a typical run with nvar=24,
nxb=nyb=nzb=8, and maxblocks = 125, these amounts to 98 MB of
memory.
On most platforms, you can use the size command to find the
amount of memory needed by the application. At present, very
little of FLASH is dynamically allocated, so this should
provide an accurate report of the memory usage. For the
above example, the memory reported by size for FLASH 1.61 is
205 MB. This will vary slightly by problem.
The most accurate measurement of the memory used by FLASH can
be obtained at runtime by defining
memory_stat_freq = 10
in your flash.par. This will output memory statistics to
flash.log every 10 timesteps (set it equal to any other number
to change the frequency). This uses the standard UNIX library
call getrusage to return the amount of memory allocated.
Q2.4 In the runtime parameters, what is meant by "cutoff values", for
example, small, smlrho, smallp/e/t/u/x ?
In the PPM hydrodynamics module, these values are used to
constrain the different hydro variables from falling to
arbitrarily small values. They should be set to values that
are realistic for the problem you are working on.
If you are using a realistic equation of state, sometimes
roundoff error in regions of high degeneracy prevent you from
finding a temperature corresponding to the internal energy.
This is because in these regions, the EOS is a very weak
function of temperature. Setting smallt to a reasonable
value can help out in this case.
Q2.5 How do I set the boundary conditions with FLASH? Is this a
parameter in the flash.par file?
The boundary conditions are set in the parameter file
(typically flash.par) at runtime. They are controlled by
the runtime parameters xl_boundary_type, xr_boundary_type,
yl_boundary_type, ... (Note, older version of FLASH used
an integer parameter of the form xlboundary, ...).
Currently, the following values are recognized:
"reflect", "reflecting":
standard reflecting boundary -- no flux through the boundary.
"outflow", "neumann", "zero-gradient":
give all variables a zero-gradient in the guardcells to allow
material to glow off the boundary.
"periodic":
standard periodic boundary conditions -- these are implemented
by the meshing package and not tot_bnd.F90.
"hydrostatic":
provide pressure support according to hydrostatic equilibrium.
"user":
user supplied boundary conditions.
Normal boundary conditions are handled in tot_bnd.F90 and fill
the guardcells of blocks at the physical boundary appropriately.
User boundary conditions should be written in user_bnd.F90, and
placed in the setup directory for the desired problem.
Q2.6 How can I setup FLASH to run a problem with a uniform grid?
You can uniformly refine the domain by setting lrefine_min =
lrefine_max, and adjusting the value to achieve the desired
number of zones in each direction. You can then instruct the
code to no longer check for refinement by setting nref to a
large integer -- this determines the number of timesteps
between refinement checks.
Running the code in this fashion will give the same level of
accuracy as a uniform mesh code, but it will still have some
of the AMR overhead associated with it.
Q2.7 What does the version number (i.e. FLASH 2.0.20001129) mean?
The version number indicates the major version (2.0) and
release date (2000-11-29) of the code used for a run. The
release date is changed automatically each night, if there
were any commits made to the source repository. This number
is contained in the file RELEASE.
At compile time, a routine called flash_release() is created,
which returns a string containing the version of FLASH in
the directory that the build was executed from. This version
number is stored in the flash.log file and any of the HDF
output files.
Q2.8 What coordinate systems does FLASH support?
Currently, FLASH only supports cartesian geometry (1, 2, and 3-d),
2-d cylindrical coordinates (r, z), and 1-d spherical coords (r).
To setup a problem in cylindrical coordinates, you use the
igeom{x,y,z} parameters in flash.par. The correct settings
for 2-d cylindrical are:
igeomx = 1
igeomy = 0
igeomz = 3
This will put the cylindrical radial coordinate in the first
dimension ('x' in the code), and the cylindrical z coordinate
in the second dimension ('y' in the code).
To extend FLASH to other coordinate systems, several routines
will need to be modified. The geometry factors that enter
the divergences and gradients in the fluid equations will
have to be inserted. The flux conservation step will also
need to be modified so a proper area weighting which knows
about the spherical geometry is performed. This is
controlled by the routines convert_flux_dens_to_tot and
convert_flux_to_to_dens. Finally, the interpolants used when
a new block is created will need to be modified. A version
of the prolongation/restriction routines for 1-d spherical
and 2-d cylindrical coordinates is provided in
source/mesh/amr/paramesh2.0/geometry/. This can be used
as a template for other coordinate systems.
This does not address the issue of a coordinate singularity
at the pole for spherical coordinates. This will need to be
handled specially.
Finally, some sort of visualization package that understands
an adaptive, non-cartesian grid will also need to be written.
Q2.9 How can I get FLASH to refine a particular region of the grid?
By default the refinement criteria is to test on the second
derivative of the pressure and density, and refine where this
is high. You can apply this derivative test to any other
variable by setting refine_var_3 = "temp" (for example), in
your flash.par. To do a more customized refinemnet, place a
copy of source/mesh/mark_ref.F90 in your setup directory.
When you setup the problem, this will override the default
version. Then use MarkRefLib (there is documentation in the
header of that file) to refine a rectangular or circular
region on the grid, but putting a call to the appropriate
method in MarkRefLib in your mark_grid_refinement routine.
This should come after the tests on the second derivative, and
before the checks that ensure that all blocks are between
lrefine_min and lrefine_max levels.
Section 3: Runtime Errors
=========================
Q3.1 The detonation problem dies when after the first timestep, with
the error message: matrix is structurally singular, rank = 1,
when running on an SGI
The MIPS Pro 7.3.X series of compilers do not work properly
with FLASH. Try dropping down to the 7.2 series, or compile
with out the -IPA switch. Skipping the interprocedural
inlining will significantly affect performance.
*update* This problem is fixed by the 7.3.2.1m series
compilers. A test suite comparison of the 7.2 series and
7.3.1.2 compilers found no differences in the FLASH results.
Q3.2 I get the an mmap error when running a large job (>~ 32
processors) on an SGI
Try recompiling and linking with the -64 switch (see the ABI
man page). This will create a 64-bit executable. You will
need to link in the 64-bit versions of the HDF libraries.
Q3.3 FLASH runs for a while but all of a sudden it stops, without
printing any errors to stdout -- what's going on?
Most likely you've exceed the maximum number of blocks that
you have allocated on a processor -- this is controlled by
the maxblocks parameter. There may be an error message in
the amr_log file generated by the PARAMESH library. Possible
errors include:
ERROR memory overflow in restrict
No. of blocks per processor exceeds maxblocks
There are two ways to fix this problem. Either increase the
number of processors you are using or increase the number of
blocks per processor.
To increase the number of blocks per processor, you need to
rerun setup with the -maxblocks flag. For example, to setup
the sedov problem with 1000 blocks per processor, use
./setup sedov -auto -maxblocks=1000
You want to ensure that the resulting executable fits into
the available memory on a processor (leaving room for the
operating system). You can check the size of the memory
taken by the executable with the size command. Since flash
uses very little dynamically allocated memory, this is a good
measure of the memory requirements of FLASH. The default
values of maxblocks are 500 for 2-d and 200 for 3-d.
Q3.4 I can compile FLASH with HDF5 fine, but when I run I get an error
-- ``error while loading shared libraries: libhdf5.so.0''. How do
I get HDF5 output to work?
You've installed the shared-object library for HDF5, and
linked to it fine, because you specified the location of the
library using -L on the link line. However, this library is
not in your library path, so when the executable is run, and
tries to load it, it cannot find it. Try setting the
LD_LIBRARY_PATH environment variable to the location of the
library. For example, under tcsh:
setenv LD_LIBRARY_PATH /opt/HDF5-1.4.2-patch1/lib/
Q3.5 FLASH segmentation faults on an IBM when running on multiple
processors, what's up?
There is a bug in either FLASH (which I cannot find) or
the AIX compilers that prevents runtime_parameters.F90 from
working on multiple processors when optimized with -O3 or
higher. If compiled with -O3, a segmentation fault will
arise, because the pointer to the head of the integer
linked list magically becomes null.
The current work around is to compile runtime_parameters.F90
with -O2 -- everything else can handle -O3. Add a rule
to your Makefile.h for runtime_parameters.o that uses less
optimization (i.e. FFLAGS_TEST instead of FFLAGS_OPT).
Q3.6 When I run FLASH on an IBM machine using the AIX compilers, I
get far more blocks than I do on other platforms -- how do
I fix this?
Don't use -qipa or -qhot with FLASH. It just doesn't work.
The issue is somewhere in the Paramesh library, but it has
not been worked though.
If you are insistent, you can try compiling all of amr_*.F90
without -qipa/-qhot, and the rest with these flags, but we've
never tested FLASH in this manner, and do not support it.
Section 4: Extending FLASH
==========================
Q4.1 How do I create a setup that reads in a 1-dimensional model and
maps it onto the FLASH domain?
An example of such a setup is provided in the sample_map problem.
The input file is flexible, and will attempt to match the
variables contained in the file to those carried by FLASH. The
current sample_map setup can map the initial model along any
coordinate direction, or as a circle or sphere.
The reading of the inputfile and reorganization of the variables
is handled by init_1d.F90. Alternate versions of init_1d.F90
that understand hydrostatic equilibrium are available in
source/util/initialization/.
Q4.2 How do I add a new problem to FLASH?
step 1: creating the new directory
Create a directory under FLASH2.X/setups/ for your new
problem. All the problem specific files should be put into
this directory. When you run setup, links to these files
will be made in the object directory.
There are two files that are necessary in this directory, a
Config file which list the modules that are required for the
setup, and an init_block.F file that initializes a block of
data. The easiest way to write these files is to use another
setup as a template.
step 2: writing your Config file
To build a Config file, copy an existing Config from one of
the other setups -- choose one that incorporates the same
physics your new problem will use. Edit Config to point to
any other FLASH modules you will be using. For instance, to
use the 13 isotope alpha-chain network, add the line:
REQUIRES source_terms/burn/aprox13
To add constant gravity, add the line:
REQUIRES gravity
The Config file also lists the runtime parameters your
initialization function will use generate the initial
conditions. For example, the Config file for the
detonation problem has a line:
PARAMETER rho_ambient REAL 2.e8
This creates a runtime parameter, rho_ambient, which is
a floating point quantity, and has a default value of 2.e8.
init_block can access this variable when initializing
the data. This default value of this variable can be set
in flash.par by including a line
rho_ambient = 1.e8
to set it to 1.e8 for the current run. Add any parameters
you need to describe the initialization of your new problem
to your new Config.
step 3: writing your init_block.F
To write the function that initializes the data in each AMR
block, it is best to copy an existing init_block.F into your
current directory. The AMR variable and tree data, the
runtime parameters (e.g. rho_ambient that we defined above),
and physical constants are obtained through database calls.
database. The variables are then filled to give the desired
initial conditions and returned to the database.
The example setup demonstates how to set the variables and
return them to the FLASH database.
Section 5: Physics Modules
==========================
Q5.1 How do I run a problem that includes thermal diffusion?
Instead of the default hydro module (ppm), you need to use
ppm/diffuse for this. This will replace the stub diffuse()
function in ppm/ with one that correctly adds the heat flux to
the energy fluxes during the hydro step.
The conductivity coefficient should be provided by one of
the conductivity routines in materials/conductivity/.
Q5.2 What's the difference between helm_table.dat and
helm_table.bdat? Why can't I find helm_table.bdat anywhere in
the source tree?
For maximum portability, the table used by the Helmholtz free
energy based EOS is in (ASC)I. This can take a while to read in
on machines with distributed file systems. To speed things up,
a binary table, helm_table.bdat, is looked for first, and read
in if present. Otherwise, the (ASC)I table is read, and the
binary equivalent is generated, for use with subsequent restarts.
Unfortunately, because of endian differences between computing
platforms, we cannot provide a portable binary table with FLASH.
Section 6: I/O Questions
========================
Q6.1 What is the difference between the output files:
name_hdf_plt_cnt_0000
name_hdf_chk_0000?
The files denoted by "chk" are checkpoint files, which are
used to restart a simulation from the point when the file was
created.
The "plt" files are plotfiles, which typically contain only a
subset of the variables, and may be single precision.
Additionally, setting the runtime parameter ``corners'' to
.TRUE. will interpolate the data to the cell corners before
outputting, which may be useful for some visualization
techniques.
Q6.2 I am submitting a FLASH job in a queue with an 8 hour run limit,
and I want to ensure that I generate a checkpoint file before
the job is killed -- is there an easy way to do this?
FLASH has a parameter called ``wall_clock_checkpoint'' which
is the time in seconds between checkpoints. This counter is
independent of the trstrt parameter, which uses simulations
time to determine when to checkpoint.
Q6.3 How do I get FLASH to use HDF5 instead of HDF 4?
The default I/O module in FLASH is currently HDF 4. The
Makefiles all include the necessary libraries by default.
When you setup and problem (like sedov) with
./setup sedov -auto
The Modules file generated will include a line that says
REQUIRES io
Since the default is hdf4, that is what will be used.
To switch to one of the HDF5 I/O modules, edit this line
to say:
REQUIRES io/amr/hdf5_parallel
or
REQUIRES io/amr/hdf5_serial
for parallel or serial I/O respectively. Then re-setup
your problem without the -auto flag,
./setup sedov
This will create soft links of the HDF5 I/O files in the
object directory. It will also add the macro ${LIB_HDF5}
to the link line in the Makefile generated by setup in
object. The Makefile.h should provide this macro for your
platform, ex:
LIB_HDF5 = -L /path/to/library -lhdf5
(there will also be one for HDF4 in Makefile.h). This will
ensure that the proper libraries get linked when the executable
is built.
Q6.4 What versions of the HDF libraries has FLASH been tested with?
The HDF 4 modules were written for HDF 4.1r2. FLASH has
run successfully with HDF versions 4.0r2, 4.1r2, and 4.1r3.
The HDF 5 module was written for HDF 5 v. 1.4.0, and has
run on 1.4.2 as well.
Q6.5 How do I set which variables are stored in a plotfile?
Up to 8 variables can be set using the short name (e.g. dens)
through the runtime parameter plot_var_1, ..., plot_var_8.
Section 7: Plotting Routines
================================
Q7.1 What version of IDL is required to run the fidlr routines?
The target version of the routines is IDL 5.4. Later versions
of IDL removed the GIF features because of patent issues. It
should be possible to replace these with the corresponding PNG
functions.
Earlier versions of IDL on the SGI (< 5.2) use the o32 ABI. This
makes building the shared-object library for HDF 5 difficult, as
the HDF 5 library is usually installed as an n32 object.
IDL 5.5 changes the way some functions work and also how strings
are defined -- these routines have been updated for 5.5 and should
work. We appreciate any bug reports with fidlr2 on IDL 5.5
Q7.2 I get lots of errors like:
fendSuffix = cw_field(suf_base, title = 'to', value = ' ', $
% Syntax error.
At: ~/FLASH2.2/tools/fidlr2/xflash.pro, Line 1239
when I run xflash off the IDL command line. What gives?
The compound widget objects are stored in the lib/
subdirectory in your IDL installation. The errors you are
getting show that IDL cannot find these, because they are not
in your path.
use:
setenv IDL_PATH ~/FLASH2.2/tools/fidlr2:${IDL_DIR}/lib:${IDL_DIR}
where IDL_DIR points to the root IDL installation directory.
{IDL_DIR}/lib should contain the cw_*.pro files. Finally, it is
assumed that the fidlr routines are in ~/FLASH2.2/tools/fidlr2
Q7.3 What other packages have been used to look at FLASH data?
The IDL routines that come with FLASH are the only officially
supported visualization routines for FLASH data at this time.
We list some visualization packages that we have found useful
below. Please note that we do not support these packages in
any way. We are interested in hearing about other
visualization software that you have found to be useful with
FLASH data.
1. VIZ:
The fidlr routines contain a script called batch.pro that
will read in a FLASH dataset, merge it onto a uniform cube,
and write out a brick file and a command file for the Viz
visualization package. Viz does volume rendering of 3-d
datasets and takes advantage of graphics hardware.
Information on Viz can be found at:
ftp://ftp.ffi.no/spub/stsk/viz/install.html
2. ChomboVis:
There has been some preliminary success with getting
ChomboVis to read FLASH datasets. In the future, we hope
to provide a conversion tool to allow ChomboVis to read
FLASH data.
Information on ChomboVis can be found at:
http://seesar.lbl.gov/anag/chombo/chomboVis/UsersGuide.html