From hudson at mcs.anl.gov  Wed Sep  3 15:46:27 2008
From: hudson at mcs.anl.gov (Randy Hudson)
Date: Wed, 3 Sep 2008 15:46:27 -0500
Subject: [FLASH-USERS] Fwd: [visit-users] VisIt 1.10.0 released
References: <7687ot$o9pnl@nspiron-2.llnl.gov>
Message-ID: <34C08A4D-0DAF-4EE2-99ED-89FC25143023@mcs.anl.gov>


FYI.  This release contains my corrections of 1) overlapping blocks  
from different refinement levels and 2) a problem reading certain  
particle files (of file format version 9, I believe).


Begin forwarded message:

> From: Eric Brugger <brugger1 at llnl.gov>
> Date: September 3, 2008 2:53:56 PM CDT
> To: visit-users at ornl.gov
> Subject: [visit-users] VisIt 1.10.0 released
> Reply-To: VisIt software users community <visit-users at email.ornl.gov>
>
>
> Hi all,
>
> VisIt 1.10 is now available.
>
> Source code and prebuilt executables are available on the visit web  
> site
> (https://visit.llnl.gov/).
>
> Changes for the 1.10 release are listed below.
>
> Eric
>
>
> Announcements:
>
> - The mesh quality metrics have been updated to use the latest  
> version of
>   the Verdict library. This affects the mesh quality metrics as well  
> as all
>   calculations involving the volume of an element. More information  
> can be
>   found in the "Features for all users" section.
> - The streamline plot has been significantly improved. More  
> information can
>   be found in the "Changes to plots" section.
>
> General features added in version 1.10:
>
> - The mesh quality metrics have been updated to use Verdict version  
> 110.
>   The new version calculates shear and hexahedral volumes more  
> accurately.
>   The Verdict volume metric is used for all volume calculations in  
> VisIt,
>   so any calculations that involve calculating the volume of a  
> hexahedral
>   element may change.  This includes many queries such as volume,  
> centroid,
>   center of mass, and spherical compactness.
> - Initial support for internationalization has been added. This  
> allows the
>   GUI to be translated into languages other than English, following  
> standard
>   Qt internationalization procedures.
> - The performance was improved for data sets with many domains (or  
> patches)
>   as well as large AMR data sets.
> - Queries that accept variables for input now have a variable widget  
> for
>   ease of entry.
> - The Overlay button has been changed so that it only creates new  
> copies of
>   the selected plots in the plot list instead of copying all plots  
> in the
>   plot list. The new behavior results in far fewer unwanted plots  
> when using
>   overlay to create new plots with a different database. Overlay was  
> also
>   changed so that it is possible to overlay plots from a specific  
> database
>   time step.
> - The Subset window is now considerably faster when selecting over a  
> large
>   number of domains.
> - The Pick Window has two new buttons: Repeat Pick will repeat a  
> pick at the
>   same location as the previous pick without displaying a new pick  
> letter but
>   using possibly updated attributes (e.g., showing additional  
> variables).
>   Display in Spreadsheet will show the previous pick location in a  
> Spreadsheet
>   plot.
>
> Advanced features added in version 1.10:
>
> - VisIt now attempts to use the loopback device (127.0.0.1) for ALL  
> local
>   connections. This should fix many startup failures on platforms  
> which are
>   related to networking issues like VPN, incorrect hostnames, or  
> firewalls
>   blocking ports on external interfaces.  To disable this feature,  
> add the
>   "-noloopback" argument when starting visit.
> - VisIt now supports the IceT library for improved rendering times.  
> IceT
>   requires a parallel version of VisIt, and is only supported in  
> scalable
>   rendering mode. Use the "-icet" command line option to enable use  
> of IceT
>   for a session.
> - VisIt's plugin managers have been reworked so that multiple  
> instances can
>   coexist in the same process. This enables simulations that are  
> instrumented
>   with libsim (and are thus VisIt compute engines) to include other  
> VisIt
>   components such as the VisIt Python interface. A simulation that  
> is both
>   a VisIt CLI and a VisIt compute engine can create plots using  
> VisIt's
>   normal Python scripting but also generate the plotted data as a  
> simulation.
> - SSH port forwarding now includes more local tunnelled ports. This  
> helps
>   use port forwarding with more than one engine.
> - When all components of VisIt have been built with a version of  
> Mesa which
>   supports large offscreen images, VisIt will allow you to save  
> images up to
>   a resolution of 16k X 16k.
> - The "visitconvert" file converter tool now allows the user to set
>   values for the writing file format options. It also now supports the
>   "-assume_format" and "-default_format" input plugin specification
>   arguments.
>
> File format reader changes in version 1.10:
>
> - VisIt now supports the UNIC file format.
> - VisIt now supports the PFLOTRAN file format, including automatic
>   decomposition of data for parallel I/O and computation.
> - The FLASH reader has been enhanced to read particles of file format
>   version 9. The reader should now read all files with particles.
> - The FLASH reader has been fixed to, again, prevent coincident  
> blocks from
>   different refinement levels from being drawn over one another.
> - The Tecplot reader has received several enhancements:
>
>     - The reader can read binary Tecplot files.
>     - It now handles DOS-formatted text files correctly.
>     - The curves it generates can now be used in expressions
>     - It supports newer versions of the Tecplot ASCII format  
> specification.
>     - It will now correctly guess coordinate variables even with units
>       (e.g. "meters") in the variable names.
>
> - The XDMF reader has been fixed so that it no longer causes memory  
> problems
>   when reading meshes of type VxVyVz, which are curvilinear meshes  
> where the
>   coordinates exist in separate HDF5 arrays.
> - The XDMF reader has been fixed so that it can also read HDF data  
> items of
>   type char, unsigned char, int, and unsigned int. It could already  
> read
>   float and double.
> - The XDMF reader now supports a BaseIndex attribute as an  
> Information field
>   in a Grid. The BaseIndex specifies the location of a structured  
> grid within
>   either a rectilinear or curvilinear multiblock mesh.
> - VisIt now supports various changes made in the Nek3D file format.
> - The BOV reader has been optimized to perform better when using a  
> large
>   number of processors. Previously, all of VisIt's processors read  
> the same
>   header file simultaneously, which severely affects parallel  
> performance
>   on some machines. In addition, the BOV reader now correctly  
> supports large
>   (4GB or more) files.
> - The VTK reader will now read 'CYCLE' from the FieldData (both  
> legacy and
>   xml formats). It also fully supports the "Try harder to get accurate
>   cycles/times" option.
> - The EnSight reader now correctly supports wildcard substitution in  
> EnSight
>   files.
> - VisIt automatically adds mesh quality expressions for curvilinear  
> and
>   unstructured meshes. However, it limits the number of expressions  
> it adds
>   (when faced with a large number of meshes) to not incur  
> performance costs.
>   The mechanism for choosing which meshes receive the mesh quality
>   expressions has been improved to pick the most important meshes.
> - A crash was fixed for the TimeVaryingExodus file format.
> - The DDCMD reader was enhanced to support reading "b" field types  
> and to
>   be able to plot the stress tensor.
> - The PlainText reader now generates curves which can be used in  
> expressions.
>   It also always exposes the coordinate arrays as variables to  
> mitigate the
>   repercussions of incorrect coordinate-variable guessing.
> - The CHGCAR (VASP) reader can now both automatically domain  
> decompose data
>   files when reading them, allowing these readers to obtain speedups  
> through
>   both parallel I/O and parallel computation.
> - The Vista/Diablo format no longer crashes on some 64-bit systems.
> - The Protein Data Bank format now exposes the Temperature and  
> Occupancy
>   Factor columns as new variables.
> - An off by one error was fixed in the PDB reader, ensuring that the  
> correct
>   material names are used.
> - The VASP, TFT, MM5, basic NETCDF, FITS, Cale and Silo readers now  
> generate
>   curves which can be used in expressions.
>
> Changes to VisIt's plots in version 1.10:
>
> - The Streamline plot has been significantly improved.
>
>      - It can now integrate streamlines across domain boundaries.
>      - It now works correctly in both serial and parallel (including
>        distributed memory parallelism).
>      - It has a parallel processing mode that allows for  
> parallelization
>        to occur over streamlines, allowing for large data sets to be
>        processed with limited resources. This mode requires ghost data
>        and knowledge of the extents of each domain. If that data is  
> not
>        available, it can still create correct streamlines, albeit by
>        processing all the domains.
>      - The integration methods are more numerically correct than those
>        previously used.
>      - Two dimensional streamlines can no longer be easily obscured by
>        other plots, such as the Pseudocolor plot.
>
> - The Spreadsheet plot's data window has been fixed on the MacOS X  
> platform
>   so the File, Edit, and Operations menu are once again available as  
> they
>   are on other platforms.
> - Ray-casted volume rendering would sometimes incorrectly cull away  
> domains
>   with non-square windows. This bug has been fixed.
> - The Histogram plot now does its default weighting by frequency.
> - The Vector plot now has the ability to only show one vector per  
> original
>   cell or node. This is useful when making Vector plots from data  
> which has
>   been clipped -- or any similar process which divides cells or  
> creates new
>   nodes. This option is enabled by default.
> - The Vector plot now uses the "Restrict to" number of vectors as a  
> value
>   over the whole problem, not just a single domain. This improves  
> consistency
>   between single- and multi-block problems, and for file formats which
>   automatically decompose data for a variable number of processors.
> - Curve plots now have labels if they were loaded from files or  
> generated by
>   expressions or queries.
>
> Changes to VisIt's operators in version 1.10
>
> - A memory issue with the Clip operator was fixed. This issue led to
>   intermittent crashes previously.
> - VisIt now provides a "Dual Mesh Operator" to aid with using the  
> resample
>   operator on images. This operator only works on rectilinear grids  
> and
>   creates the dual mesh of the input, with the following two  
> conversion
>   modes:
>
>       - Nodes to Zones: Creates output zones centered at input nodes  
> and
>         converts point data to cell data
>       - Zones to Nodes: Creates output nodes centered at input zone  
> centers
>         and converts cell data to point data.
>
>         You can explicitly choose how you want to convert or use Auto,
>         which looks at the primary variable to determine the proper
>         direction.
>
>         For conversion examples see:
>
>         "http://visitusers.org/index.php?title=Dual_Mesh_Operator"
>
> - The Transform Operator now supports an arbitrary 3x3 linear  
> transform
>   matrix.
> - A problem with using the Box Operator on Curves was fixed.
>
> Changes to VisIt's expression language in version 1.10:
>
> - There is a new "exp" function for calculating e^2.
> - There is a new "transpose" function for tensor data.
> - The Laplacian function was reimplemented for rectilinear data to  
> be more
>   efficient and to only require a single layer of ghost cells.
> - The area and revolved volume functions now support arbitrary 2D
>   polygons.
> - New functions for "min_corner_angle" and "max_corner_angle" were  
> added.
>   This function is not exposed by default, as it gives ambiguous  
> answers
>   vis-a-vis arcsin.
> - In the past, expressions have often gotten confused as to whether  
> they
>   are scalars or vectors. This issue should be much improved.
> - The expression language now supports using backslashes to escape the
>   next character. For example, some variable names like "dist (cm)"  
> can
>   now be specified either using the original quoting mechanism, i.e.
>   "<dist (cm)>", or with backslashes, i.e. "dist\ \(cm\)"
> - Backslashes may also be used as directory separators in file  
> names. Note,
>   however, that due to the backslash-escaping mechanism, you must  
> use two
>   successive backslashes here, e.g. "\\path\\to\\file.vtk". This is  
> only a
>   convenience; forward slashes still work the same as before.
>
> Changes to VisIt's picks and queries in version 1.10:
>
> - Query-over-time of a non-default variable now uses the correct  
> variable
>   name and units in the legend.
> - Pick-through-time now uses the variable name and units for the y- 
> axis
>   labels.
> - Pick no longer gets confused about which variable to use when  
> performed
>   after a doing a Query of a non-default variable.
> - Pick now works on time-curves.
> - Queries such as NumNodes and Variable Sum now work correctly with  
> material
>   selection enabled.
> - The area and revolved volume queries now support arbitrary 2D  
> polygons.
> - The Hohlraum Flux query now does a better job of issuing warnings in
>   error conditions and not crashing. Also, this query now gives  
> output in
>   full double precision.
> - The Shapelet Decomposition query was updated to retain the original
>   spatial extents in the recomposition output.
>
> Changes to VisIt's command-line interface in version 1.10:
>
> - The "OverlayDatabase" function now accepts an optional second  
> argument
>   for specifying a time state.
> - When bringing up the CLI from the GUI's "Controls->Command"  
> window, it is
>   no longer necessary to enter a string to activate the Execute  
> button. (The
>   CLI can now be launched directly without a dummy command.)
> - Python callbacks no longer fail silently. If you have registered a
>   function with an incorrect signature, you will now get a proper  
> error
>   message.
> - A hang when attempting "OpenGUI()" from the cli on Windows has  
> been fixed.
>
> Other bugs fixed in version 1.10:
>
> - If you combine a ray-casted volume rendering with transparent  
> geometry,
>   VisIt now issues an error message and no longer hangs.
> - The "visit -movie" movie generation script once again can detect the
>   engine configuration used to generate the plots in a session file  
> and can
>   reuse that configuration when generating a movie.
> - For windows platforms, running "visit -cli -o", "visit -cli -s", or
>   double-clicking a ".py" now correctly parses paths and works  
> correctly.
> - Macro recording for 2D zooming no longer produces invalid Python  
> code for
>   setting the 2D view attributes.
> - Macro creation now does more checking to make sure that macro  
> names are
>   valid, which prevents problems when the macros are actually  
> registered.
> - VisIt's libsim library used a non-zero idle timeout that slowed down
>   polling simulations.
> - Restore session from sources now works again.
> - VisIt displays the files from localhost in the File panel when the
>   "-launchengine" argument is provided to launch a remote compute  
> engine.
> - If you apply a resample operator to a FilledBoundary plot, VisIt now
>   issues a warning and no longer crashes.
> - On Macs, if you used the Variables dropdown to change the variable  
> of a
>   plot and if that variable was invalid (e.g. a bad expression),  
> then VisIt
>   will no longer crash.
> - The "Lock Tools" icon in the toolbar is now grouped correctly with  
> the
>   other "Lock" icons.
> - The deprecated Parallel Axis plot has been removed. Use the new  
> Parallel
>   Coordinates plot instead.
> - Issues with log-log scaling of mulitple curves have been resolved.
> - VisIt's check for X11 terminals on Mac OS X has been improved.
> - Materials defined on point meshes in an instrumented simulation  
> cannot
>   be plotted successfully.
>
> Changes to configuration files in version 1.10:
>
> - Host profiles for ORNL's visualization cluster, lens, have been  
> added.
> - Host profiles for ORNL's Cray XT4/5, jaguar, have been added.
> - The host profiles for LLNL's yana system have been modified to use
>   SLURM and Moab.
> - The host profiles for LLNL's hopi system have been modified to use
>   SLURM and Moab.
> - The parallel hardware accelerated host profile for LLNL's gauss  
> cluster
>   has been modified for Chaos 4.
> - The host profiles for LLNL's up system have been modified to use  
> Moab.
> - "-switch ib" has been removed from all of LLNL's host profiles  
> since it
>   is no longer necessary.
>
> Changes for VisIt developers in version 1.10:
>
> - Development on Windows can now be done directly from the SVN  
> repository,
>   as the build process has been modified to use the native source tree
>   instead of a modified one.
> - The Klocwork tool was applied to VisIt and many potential bugs  
> were found
>   and fixed.
> - The method for running all of VisIt's perl scripts was changed,  
> making
>   launching somewhat simpler, internally.
> - The source code was improved to reduce the number of compiler  
> warnings.
>
> --
> List subscription information: https://email.ornl.gov/mailman/listinfo/visit-users
> Searchable list archives: https://email.ornl.gov/pipermail/visit-users
>


Randy.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://flash.uchicago.edu/pipermail/flash-users/attachments/20080903/245e610d/attachment.html 

From miesch at ucar.edu  Fri Sep  5 18:18:34 2008
From: miesch at ucar.edu (Mark Miesch)
Date: Fri, 5 Sep 2008 17:18:34 -0600
Subject: [FLASH-USERS] Vector field visualization with VISIT
Message-ID: <668E428E-3AEB-4400-9A2B-6503AAD48337@ucar.edu>


Hi all -

A quick question about  using VISIT for FLASH visualization.

I'd like to make streamline plots of the magnetic field from an
MHD FLASH simulation.  I can read the data into VISIT just fine
but it interprets magx, magy and magz as scalar fields.  How
do I let VISIT know that these are three components of a
vector field so I can enable streamline and vector plots?

Many thanks,
- Mark


Mark Miesch
HAO/NCAR
Boulder, CO 80307-3000
303-497-1582
miesch at ucar.edu



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://flash.uchicago.edu/pipermail/flash-users/attachments/20080905/9d82b561/attachment.html 

From bernalcg at astroscu.unam.mx  Fri Sep  5 18:32:29 2008
From: bernalcg at astroscu.unam.mx (Giovanny Bernal)
Date: Fri, 5 Sep 2008 18:32:29 -0500
Subject: [FLASH-USERS] Vector field visualization with VISIT
In-Reply-To: <668E428E-3AEB-4400-9A2B-6503AAD48337@ucar.edu>
References: <668E428E-3AEB-4400-9A2B-6503AAD48337@ucar.edu>
Message-ID: <D44E9B11-99B8-424E-AF22-5AE9B5A8F17F@astroscu.unam.mx>

Hi Mark,

I do this in Visit 1.8.1 (for flash2.5 data)
1. controls+expressions
2. New --> Name: Bfield (for example), Type: Scalar (pseudocolor or  
countor) or vector (Bfield vector)
3. For scalar: sqrt(magx*magx+magy*magy) + apply
5. For vector {magx,magy} + apply
6. Dismiss... go to plot and enjoy

I hope that this help


El 05/09/2008, a las 06:18 p.m., Mark Miesch escribi?:

>
> Hi all -
>
> A quick question about  using VISIT for FLASH visualization.
>
> I'd like to make streamline plots of the magnetic field from an
> MHD FLASH simulation.  I can read the data into VISIT just fine
> but it interprets magx, magy and magz as scalar fields.  How
> do I let VISIT know that these are three components of a
> vector field so I can enable streamline and vector plots?
>
> Many thanks,
> - Mark
>
>
> Mark Miesch
> HAO/NCAR
> Boulder, CO 80307-3000
> 303-497-1582
> miesch at ucar.edu
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://flash.uchicago.edu/pipermail/flash-users/attachments/20080905/06c49d00/attachment.html 

From zuhone at flash.uchicago.edu  Fri Sep  5 18:33:45 2008
From: zuhone at flash.uchicago.edu (John ZuHone)
Date: Fri, 5 Sep 2008 18:33:45 -0500
Subject: [FLASH-USERS] Vector field visualization with VISIT
In-Reply-To: <668E428E-3AEB-4400-9A2B-6503AAD48337@ucar.edu>
References: <668E428E-3AEB-4400-9A2B-6503AAD48337@ucar.edu>
Message-ID: <DE4D7FF7-F891-466E-85A4-A43B134479C5@flash.uchicago.edu>

Hello Mark,

It's actually fairly simple. Using the "Expressions..." item in the  
"Controls..." menu, you can create a new variable of a vector type.  
Just choose a name, choose "Vector Mesh Variable" from the "Type" drop- 
down box, and then put the variable in this format in the "Definition":

{magx, magy, magz}

which creates a three-dimensional vector from the three scalar  
components. You'll probably have to choose the variable names from  
"Insert Variable" since they're not likely to be exactly magx, etc.  
but some variant of those depending on your version of VisIt and  
FLASH. This does work, though, as I use it to generate velocity  
vectors from velx, vely, and velz.

Best,

John ZuHone

On Sep 5, 2008, at 6:18 PM, Mark Miesch wrote:

>
> Hi all -
>
> A quick question about  using VISIT for FLASH visualization.
>
> I'd like to make streamline plots of the magnetic field from an
> MHD FLASH simulation.  I can read the data into VISIT just fine
> but it interprets magx, magy and magz as scalar fields.  How
> do I let VISIT know that these are three components of a
> vector field so I can enable streamline and vector plots?
>
> Many thanks,
> - Mark
>
>
> Mark Miesch
> HAO/NCAR
> Boulder, CO 80307-3000
> 303-497-1582
> miesch at ucar.edu
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://flash.uchicago.edu/pipermail/flash-users/attachments/20080905/f68a43fa/attachment.html 

From kdere at gmu.edu  Sun Sep  7 12:17:53 2008
From: kdere at gmu.edu (Ken Dere)
Date: Sun, 07 Sep 2008 13:17:53 -0400
Subject: [FLASH-USERS] flash3 plugin for visit 1.10.0
Message-ID: <48C40CC1.4050901@gmu.edu>

Hi

I have been unable to build the flash3 plugin for visit. when running make,
the end of the message, indicating the error is:

from avtFLASHFileFormat.C:42:
/usr/include/c++/4.3/backward/backward_warning.h:32:2: warning: #warning 
This
file includes at least one deprecated or antiquated header which may be
removed without further notice at a future date. Please use a 
non-deprecated
interface with equivalent functionality instead. For a listing of 
replacement
headers and interfaces, consult the file backward_warning.h. To disable 
this
warning use -Wno-deprecated.
avtFLASHFileFormat.C: In member function ?vtkPolyData*
avtFLASHFileFormat::GetMortonCurveSubset(int)?:
avtFLASHFileFormat.C:1058: error: no matching function for call
to ?find(__gnu_cxx::__normal_iterator<int*, std::vector<int,
std::allocator<int> > >, __gnu_cxx::__normal_iterator<int*, 
std::vector<int,
std::allocator<int> > >, int&)?
make: *** [avtFLASHFileFormat.o] Error 1

any help would be appreciated.

Ken Dere


From flash-users at flash.uchicago.edu  Wed Sep 10 09:38:10 2008
From: flash-users at flash.uchicago.edu (flash-users at flash.uchicago.edu)
Date: Wed, 10 Sep 2008 09:38:10 -0500 (CDT)
Subject: [FLASH-USERS] [SPAM] September 79% 0FF
Message-ID: <20080910155043.2246.qmail@hpproxy.citechco.net>

An HTML attachment was scrubbed...
URL: http://flash.uchicago.edu/pipermail/flash-users/attachments/20080910/3f5f88ee/attachment.html 

From hudson at mcs.anl.gov  Wed Sep 10 12:42:12 2008
From: hudson at mcs.anl.gov (Randy Hudson)
Date: Wed, 10 Sep 2008 12:42:12 -0500
Subject: [FLASH-USERS] flash3 plugin for visit 1.10.0
In-Reply-To: <48C40CC1.4050901@gmu.edu>
References: <48C40CC1.4050901@gmu.edu>
Message-ID: <FBFCA89F-E76C-4899-9537-9BBB5C9AA7CB@mcs.anl.gov>


Ken,

Unless you want to build changes you've made to the plugin, you don't  
need to build it with visit 1.10.0.  That visit release has all my  
changes.


On Sep 7, 2008, at 12:17 PM, Ken Dere wrote:

> Hi
>
> I have been unable to build the flash3 plugin for visit. when  
> running make,
> the end of the message, indicating the error is:
>
> from avtFLASHFileFormat.C:42:
> /usr/include/c++/4.3/backward/backward_warning.h:32:2: warning:  
> #warning This
> file includes at least one deprecated or antiquated header which may  
> be
> removed without further notice at a future date. Please use a non- 
> deprecated
> interface with equivalent functionality instead. For a listing of  
> replacement
> headers and interfaces, consult the file backward_warning.h. To  
> disable this
> warning use -Wno-deprecated.
> avtFLASHFileFormat.C: In member function ?vtkPolyData*
> avtFLASHFileFormat::GetMortonCurveSubset(int)?:
> avtFLASHFileFormat.C:1058: error: no matching function for call
> to ?find(__gnu_cxx::__normal_iterator<int*, std::vector<int,
> std::allocator<int> > >, __gnu_cxx::__normal_iterator<int*,  
> std::vector<int,
> std::allocator<int> > >, int&)?
> make: *** [avtFLASHFileFormat.o] Error 1
>
> any help would be appreciated.
>
> Ken Dere


Randy.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://flash.uchicago.edu/pipermail/flash-users/attachments/20080910/588c6936/attachment.html 

From mateuszr at umich.edu  Sun Sep 14 18:23:53 2008
From: mateuszr at umich.edu (Mateusz Ruszkowski)
Date: Sun, 14 Sep 2008 19:23:53 -0400 (EDT)
Subject: [FLASH-USERS] "relocation truncated to fit" error
In-Reply-To: <FBFCA89F-E76C-4899-9537-9BBB5C9AA7CB@mcs.anl.gov>
References: <48C40CC1.4050901@gmu.edu>
	<FBFCA89F-E76C-4899-9537-9BBB5C9AA7CB@mcs.anl.gov>
Message-ID: <Pine.LNX.4.64.0809141920580.25316@lem.astro.lsa.umich.edu>


  Hi all,

I am getting the following linking error:


r_buildSummary.o tmr_create.o tmr_etime.o tmr_findTimerIndex.o 
tmr_getMaxCallStackDepth.o
tmr_getMaxTimerParents.o tmr_init.o tmr_lookupIndex.o tmr_stackLib.o 
tree.o umap.o
user_coord_transfm.o ut_conversionInterface.o ut_convertToArrayIndicies.o
ut_convertToMemoryOffset.o ut_fndpos.o ut_hunt.o 
ut_interpolationInterface.o ut_polint.o
ut_quadraticInterpol.o workspace.o -L /usr/local/hdf5-1.6.6-intel-mva/lib 
-lhdf5 -lz
-L/usr/mpi/intel/mvapich2-1.0.2p1/lib -lfmpich -lmpich -libverbs -libumad 
-lpthread
/usr/local/intel/fce/10.1.013/lib/libimf.so: warning: warning: feupdateenv 
is not implemented
and will always fail
Grid_conserveField.o: In function `grid_conservefield_':
Grid_conserveField.F90:(.text+0xe): relocation truncated to fit: 
R_X86_64_PC32 against symbol
`tree_mp_lnblocks_' defined in COMMON section in tree.o
Grid_conserveField.F90:(.text+0x47): relocation truncated to fit: 
R_X86_64_32S against symbol
`tree_mp_nodetype_' defined in COMMON section in tree.o
Grid_conserveField.F90:(.text+0x98): relocation truncated to fit: 
R_X86_64_PC32 against symbol
`tree_mp_lnblocks_' defined in COMMON section in tree.o
Grid_conserveField.F90:(.text+0xcc): relocation truncated to fit: 
R_X86_64_32S against symbol
`tree_mp_nodetype_' defined in COMMON section in tree.o
Grid_conserveField.F90:(.text+0x2b9): relocation truncated to fit: 
R_X86_64_32S against symbol
`physicaldata_mp_bedge_facex_z_' defined in COMMON section in 
physicaldata.o
Grid_conserveField.F90:(.text+0x2c4): relocation truncated to fit: 
R_X86_64_32S against symbol
`physicaldata_mp_bedge_facex_z_' defined in COMMON section in 
physicaldata.o
Grid_conserveField.F90:(.text+0x2d3): relocation truncated to fit: 
R_X86_64_32S against symbol
`physicaldata_mp_bedge_facex_z_' defined in COMMON section in 
physicaldata.o
Grid_conserveField.F90:(.text+0x2de): relocation truncated to fit: 
R_X86_64_32S against symbol
`physicaldata_mp_bedge_facex_z_' defined in COMMON section in 
physicaldata.o
Grid_conserveField.F90:(.text+0x309): relocation truncated to fit: 
R_X86_64_32S against symbol
`physicaldata_mp_bedge_facex_z_' defined in COMMON section in 
physicaldata.o
Grid_conserveField.F90:(.text+0x310): relocation truncated to fit: 
R_X86_64_32S against symbol
`physicaldata_mp_bedge_facex_z_' defined in COMMON section in 
physicaldata.o
Grid_conserveField.F90:(.text+0x46b): additional relocation overflows 
omitted from the output
gmake: *** [flash3] Error 1
[mateuszr at galaxy object]$


The problem goes away if I reduce the number of maxblocks to 100 or
if I set nxb=nyb=nzb=8 instead of nxb=nyb=nzb=16 but this
"solution" is not optimal for computational reasons. I am wondering
if there is some compilation
option to fix this problem. According to Google there are some
compilation options such as -mcmodel=medium -fPIC -i-dynamic. I tried 
these but got very similar error messages, i.e., all related to the
"relocation truncated to fit" linking error.

I would be grateful for some sugestion if anybody encountered a similar
problem and managed to fix it.

   thanks,
     Mateusz

P.S. I am using ifort with
/usr/mpi/intel/mvapich2-1.0.2p1/bin/mpif90 -c -r8 -i4 -O3 -real_size 64 
-DMAXBLOCKS=200 -DNXB=16 -DNYB=16 -DNZB=16 -DN_DIM=3




From brockp at umich.edu  Sun Sep 14 18:38:22 2008
From: brockp at umich.edu (Brock Palen)
Date: Sun, 14 Sep 2008 19:38:22 -0400
Subject: [FLASH-USERS] "relocation truncated to fit" error
In-Reply-To: <Pine.LNX.4.64.0809141920580.25316@lem.astro.lsa.umich.edu>
References: <48C40CC1.4050901@gmu.edu>
	<FBFCA89F-E76C-4899-9537-9BBB5C9AA7CB@mcs.anl.gov>
	<Pine.LNX.4.64.0809141920580.25316@lem.astro.lsa.umich.edu>
Message-ID: <8429BD37-86F5-48D2-BDD0-D92E0538C82E@umich.edu>

-mcmodel=medium will fix it,  you just need to make sure every  
library that is giving that error is compiled with it.  You also need  
to make sure that the final link also has the option or you will get  
that error.

Also blocks=100 sounds like a problem to me, not being a flash users  
(sys admin) others will need to comment.

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



On Sep 14, 2008, at 7:23 PM, Mateusz Ruszkowski wrote:
>
>  Hi all,
>
> I am getting the following linking error:
>
>
> r_buildSummary.o tmr_create.o tmr_etime.o tmr_findTimerIndex.o  
> tmr_getMaxCallStackDepth.o
> tmr_getMaxTimerParents.o tmr_init.o tmr_lookupIndex.o  
> tmr_stackLib.o tree.o umap.o
> user_coord_transfm.o ut_conversionInterface.o  
> ut_convertToArrayIndicies.o
> ut_convertToMemoryOffset.o ut_fndpos.o ut_hunt.o  
> ut_interpolationInterface.o ut_polint.o
> ut_quadraticInterpol.o workspace.o -L /usr/local/hdf5-1.6.6-intel- 
> mva/lib -lhdf5 -lz
> -L/usr/mpi/intel/mvapich2-1.0.2p1/lib -lfmpich -lmpich -libverbs - 
> libumad -lpthread
> /usr/local/intel/fce/10.1.013/lib/libimf.so: warning: warning:  
> feupdateenv is not implemented
> and will always fail
> Grid_conserveField.o: In function `grid_conservefield_':
> Grid_conserveField.F90:(.text+0xe): relocation truncated to fit:  
> R_X86_64_PC32 against symbol
> `tree_mp_lnblocks_' defined in COMMON section in tree.o
> Grid_conserveField.F90:(.text+0x47): relocation truncated to fit:  
> R_X86_64_32S against symbol
> `tree_mp_nodetype_' defined in COMMON section in tree.o
> Grid_conserveField.F90:(.text+0x98): relocation truncated to fit:  
> R_X86_64_PC32 against symbol
> `tree_mp_lnblocks_' defined in COMMON section in tree.o
> Grid_conserveField.F90:(.text+0xcc): relocation truncated to fit:  
> R_X86_64_32S against symbol
> `tree_mp_nodetype_' defined in COMMON section in tree.o
> Grid_conserveField.F90:(.text+0x2b9): relocation truncated to fit:  
> R_X86_64_32S against symbol
> `physicaldata_mp_bedge_facex_z_' defined in COMMON section in  
> physicaldata.o
> Grid_conserveField.F90:(.text+0x2c4): relocation truncated to fit:  
> R_X86_64_32S against symbol
> `physicaldata_mp_bedge_facex_z_' defined in COMMON section in  
> physicaldata.o
> Grid_conserveField.F90:(.text+0x2d3): relocation truncated to fit:  
> R_X86_64_32S against symbol
> `physicaldata_mp_bedge_facex_z_' defined in COMMON section in  
> physicaldata.o
> Grid_conserveField.F90:(.text+0x2de): relocation truncated to fit:  
> R_X86_64_32S against symbol
> `physicaldata_mp_bedge_facex_z_' defined in COMMON section in  
> physicaldata.o
> Grid_conserveField.F90:(.text+0x309): relocation truncated to fit:  
> R_X86_64_32S against symbol
> `physicaldata_mp_bedge_facex_z_' defined in COMMON section in  
> physicaldata.o
> Grid_conserveField.F90:(.text+0x310): relocation truncated to fit:  
> R_X86_64_32S against symbol
> `physicaldata_mp_bedge_facex_z_' defined in COMMON section in  
> physicaldata.o
> Grid_conserveField.F90:(.text+0x46b): additional relocation  
> overflows omitted from the output
> gmake: *** [flash3] Error 1
> [mateuszr at galaxy object]$
>
>
> The problem goes away if I reduce the number of maxblocks to 100 or
> if I set nxb=nyb=nzb=8 instead of nxb=nyb=nzb=16 but this
> "solution" is not optimal for computational reasons. I am wondering
> if there is some compilation
> option to fix this problem. According to Google there are some
> compilation options such as -mcmodel=medium -fPIC -i-dynamic. I  
> tried these but got very similar error messages, i.e., all related  
> to the
> "relocation truncated to fit" linking error.
>
> I would be grateful for some sugestion if anybody encountered a  
> similar
> problem and managed to fix it.
>
>   thanks,
>     Mateusz
>
> P.S. I am using ifort with
> /usr/mpi/intel/mvapich2-1.0.2p1/bin/mpif90 -c -r8 -i4 -O3 - 
> real_size 64 -DMAXBLOCKS=200 -DNXB=16 -DNYB=16 -DNZB=16 -DN_DIM=3
>
>
>
>



From seyit at astro.rug.nl  Mon Sep 15 05:07:34 2008
From: seyit at astro.rug.nl (Seyit Hocuk)
Date: Mon, 15 Sep 2008 12:07:34 +0200
Subject: [FLASH-USERS] "relocation truncated to fit" error
In-Reply-To: <Pine.LNX.4.64.0809141920580.25316@lem.astro.lsa.umich.edu>
References: <48C40CC1.4050901@gmu.edu>	<FBFCA89F-E76C-4899-9537-9BBB5C9AA7CB@mcs.anl.gov>
	<Pine.LNX.4.64.0809141920580.25316@lem.astro.lsa.umich.edu>
Message-ID: <48CE33E6.8090507@astro.rug.nl>

Hi Mateusz,

For a very long time, I had the same error and nobody had the correct 
answer. I could partly solve it (meaning I can go now about 4 times 
higher in memory) by adding some flags in the Makefile.h. The place you 
put the flags are important though. Where you put your FCOMP and LINK 
add these flags "-fpic -i_dynamic" or "-i_dynamic -mcmodel=large", they 
both work. See example below. I had to experiment with a lot of number 
of flags and combinations to get it right.


FCOMP   = $(MPI_PATH)/bin/mpif90 -fpic -i_dynamic -mcmodel=large (or 
-mcmodel=medium)
CCOMP   = mpicc
CPPCOMP = mpiCC
LINK    = $(MPI_PATH)/bin/mpif90 -fpic -i_dynamic -mcmodel=large (or 
-mcmodel=medium)

Hope this helps.

Seyit






Mateusz Ruszkowski wrote:
>
>  Hi all,
>
> I am getting the following linking error:
>
>
> r_buildSummary.o tmr_create.o tmr_etime.o tmr_findTimerIndex.o 
> tmr_getMaxCallStackDepth.o
> tmr_getMaxTimerParents.o tmr_init.o tmr_lookupIndex.o tmr_stackLib.o 
> tree.o umap.o
> user_coord_transfm.o ut_conversionInterface.o ut_convertToArrayIndicies.o
> ut_convertToMemoryOffset.o ut_fndpos.o ut_hunt.o 
> ut_interpolationInterface.o ut_polint.o
> ut_quadraticInterpol.o workspace.o -L 
> /usr/local/hdf5-1.6.6-intel-mva/lib -lhdf5 -lz
> -L/usr/mpi/intel/mvapich2-1.0.2p1/lib -lfmpich -lmpich -libverbs 
> -libumad -lpthread
> /usr/local/intel/fce/10.1.013/lib/libimf.so: warning: warning: 
> feupdateenv is not implemented
> and will always fail
> Grid_conserveField.o: In function `grid_conservefield_':
> Grid_conserveField.F90:(.text+0xe): relocation truncated to fit: 
> R_X86_64_PC32 against symbol
> `tree_mp_lnblocks_' defined in COMMON section in tree.o
> Grid_conserveField.F90:(.text+0x47): relocation truncated to fit: 
> R_X86_64_32S against symbol
> `tree_mp_nodetype_' defined in COMMON section in tree.o
> Grid_conserveField.F90:(.text+0x98): relocation truncated to fit: 
> R_X86_64_PC32 against symbol
> `tree_mp_lnblocks_' defined in COMMON section in tree.o
> Grid_conserveField.F90:(.text+0xcc): relocation truncated to fit: 
> R_X86_64_32S against symbol
> `tree_mp_nodetype_' defined in COMMON section in tree.o
> Grid_conserveField.F90:(.text+0x2b9): relocation truncated to fit: 
> R_X86_64_32S against symbol
> `physicaldata_mp_bedge_facex_z_' defined in COMMON section in 
> physicaldata.o
> Grid_conserveField.F90:(.text+0x2c4): relocation truncated to fit: 
> R_X86_64_32S against symbol
> `physicaldata_mp_bedge_facex_z_' defined in COMMON section in 
> physicaldata.o
> Grid_conserveField.F90:(.text+0x2d3): relocation truncated to fit: 
> R_X86_64_32S against symbol
> `physicaldata_mp_bedge_facex_z_' defined in COMMON section in 
> physicaldata.o
> Grid_conserveField.F90:(.text+0x2de): relocation truncated to fit: 
> R_X86_64_32S against symbol
> `physicaldata_mp_bedge_facex_z_' defined in COMMON section in 
> physicaldata.o
> Grid_conserveField.F90:(.text+0x309): relocation truncated to fit: 
> R_X86_64_32S against symbol
> `physicaldata_mp_bedge_facex_z_' defined in COMMON section in 
> physicaldata.o
> Grid_conserveField.F90:(.text+0x310): relocation truncated to fit: 
> R_X86_64_32S against symbol
> `physicaldata_mp_bedge_facex_z_' defined in COMMON section in 
> physicaldata.o
> Grid_conserveField.F90:(.text+0x46b): additional relocation overflows 
> omitted from the output
> gmake: *** [flash3] Error 1
> [mateuszr at galaxy object]$
>
>
> The problem goes away if I reduce the number of maxblocks to 100 or
> if I set nxb=nyb=nzb=8 instead of nxb=nyb=nzb=16 but this
> "solution" is not optimal for computational reasons. I am wondering
> if there is some compilation
> option to fix this problem. According to Google there are some
> compilation options such as -mcmodel=medium -fPIC -i-dynamic. I tried 
> these but got very similar error messages, i.e., all related to the
> "relocation truncated to fit" linking error.
>
> I would be grateful for some sugestion if anybody encountered a similar
> problem and managed to fix it.
>
>   thanks,
>     Mateusz
>
> P.S. I am using ifort with
> /usr/mpi/intel/mvapich2-1.0.2p1/bin/mpif90 -c -r8 -i4 -O3 -real_size 
> 64 -DMAXBLOCKS=200 -DNXB=16 -DNYB=16 -DNZB=16 -DN_DIM=3
>
>



From jfg at ucolick.org  Wed Sep 17 07:41:49 2008
From: jfg at ucolick.org (James Guillochon)
Date: Wed, 17 Sep 2008 14:41:49 +0200
Subject: [FLASH-USERS] Altering Velocity Causes Anomalous Pressure
Message-ID: <48D0FB0D.8020107@ucolick.org>

Hi everyone,

I am altering the velocity of a couple of grid squares in my simulation 
in the Driver_sourceTerms function at each time step, and after a couple 
hundred steps I end up with a grid cell or two with a ridiculously high 
pressure/density, which causes the Helmholtz EOS routine to not 
converge. I was wondering if there are any other variables I should be 
altering when I give these grid cells their new velocities? Or if there 
is a better place in Flash to be adjusting the velocities than the 
Driver_sourceTerms routine?

Thanks!

- James


From tplewa at fsu.edu  Wed Sep 17 07:50:27 2008
From: tplewa at fsu.edu (Tomasz Plewa)
Date: Wed, 17 Sep 2008 08:50:27 -0400
Subject: [FLASH-USERS] Altering Velocity Causes Anomalous Pressure
In-Reply-To: <48D0FB0D.8020107@ucolick.org>
References: <48D0FB0D.8020107@ucolick.org>
Message-ID: <48D0FD13.6080404@fsu.edu>

James -

At the very least you need to update the total gas energy.

Tomek
--
James Guillochon wrote:
> Hi everyone,
>
> I am altering the velocity of a couple of grid squares in my simulation 
> in the Driver_sourceTerms function at each time step, and after a couple 
> hundred steps I end up with a grid cell or two with a ridiculously high 
> pressure/density, which causes the Helmholtz EOS routine to not 
> converge. I was wondering if there are any other variables I should be 
> altering when I give these grid cells their new velocities? Or if there 
> is a better place in Flash to be adjusting the velocities than the 
> Driver_sourceTerms routine?
>
> Thanks!
>
> - James
>   
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tplewa.vcf
Type: text/x-vcard
Size: 338 bytes
Desc: not available
Url : http://flash.uchicago.edu/pipermail/flash-users/attachments/20080917/ca50ec3b/attachment.vcf 

From jfg at ucolick.org  Wed Sep 17 07:58:55 2008
From: jfg at ucolick.org (James Guillochon)
Date: Wed, 17 Sep 2008 14:58:55 +0200
Subject: [FLASH-USERS] Altering Velocity Causes Anomalous Pressure
In-Reply-To: <48D0FD13.6080404@fsu.edu>
References: <48D0FB0D.8020107@ucolick.org> <48D0FD13.6080404@fsu.edu>
Message-ID: <48D0FF0F.2040002@ucolick.org>

OK, I will give that a try. Is there anything else I should be cautious 
about? Is the Driver_sourceTerms routine the appropriate place to do 
this sort of thing?

Thanks for your help!

Tomasz Plewa wrote:
> James -
>
> At the very least you need to update the total gas energy.
>
> Tomek
> -- 
> James Guillochon wrote:
>> Hi everyone,
>>
>> I am altering the velocity of a couple of grid squares in my 
>> simulation in the Driver_sourceTerms function at each time step, and 
>> after a couple hundred steps I end up with a grid cell or two with a 
>> ridiculously high pressure/density, which causes the Helmholtz EOS 
>> routine to not converge. I was wondering if there are any other 
>> variables I should be altering when I give these grid cells their new 
>> velocities? Or if there is a better place in Flash to be adjusting 
>> the velocities than the Driver_sourceTerms routine?
>>
>> Thanks!
>>
>> - James
>>   
>
>
> !DSPAM:10135,48d0fd1a20044307041292!


From tplewa at fsu.edu  Wed Sep 17 08:11:01 2008
From: tplewa at fsu.edu (Tomasz Plewa)
Date: Wed, 17 Sep 2008 09:11:01 -0400
Subject: [FLASH-USERS] Altering Velocity Causes Anomalous Pressure
In-Reply-To: <48D0FF0F.2040002@ucolick.org>
References: <48D0FB0D.8020107@ucolick.org> <48D0FD13.6080404@fsu.edu>
	<48D0FF0F.2040002@ucolick.org>
Message-ID: <48D101E5.1000806@fsu.edu>

An HTML attachment was scrubbed...
URL: http://flash.uchicago.edu/pipermail/flash-users/attachments/20080917/99c1a7f5/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tplewa.vcf
Type: text/x-vcard
Size: 338 bytes
Desc: not available
Url : http://flash.uchicago.edu/pipermail/flash-users/attachments/20080917/99c1a7f5/attachment.vcf 

From klaus at flash.uchicago.edu  Wed Sep 17 08:19:31 2008
From: klaus at flash.uchicago.edu (Klaus Weide)
Date: Wed, 17 Sep 2008 08:19:31 -0500 (CDT)
Subject: [FLASH-USERS] Altering Velocity Causes Anomalous Pressure
In-Reply-To: <48D0FF0F.2040002@ucolick.org>
References: <48D0FB0D.8020107@ucolick.org> <48D0FD13.6080404@fsu.edu>
	<48D0FF0F.2040002@ucolick.org>
Message-ID: <Pine.LNX.4.64.0809170815440.9831@flash.uchicago.edu>

On Wed, 17 Sep 2008, James Guillochon wrote:

> OK, I will give that a try. Is there anything else I should be cautious 
> about? Is the Driver_sourceTerms routine the appropriate place to do this 
> sort of thing?

James,

In the FLASH3 release, the Driver_sourceTerms implementation
calls Stir.  The release also contains a Stir.F90 which modifies
velocity components and adjusts energy.  You should be able to use
that as a template.

Klaus


From jfg at ucolick.org  Wed Sep 17 12:34:19 2008
From: jfg at ucolick.org (James Guillochon)
Date: Wed, 17 Sep 2008 19:34:19 +0200
Subject: [FLASH-USERS] Altering Velocity Causes Anomalous Pressure
In-Reply-To: <Pine.LNX.4.64.0809170815440.9831@flash.uchicago.edu>
References: <48D0FB0D.8020107@ucolick.org> <48D0FD13.6080404@fsu.edu>
	<48D0FF0F.2040002@ucolick.org>
	<Pine.LNX.4.64.0809170815440.9831@flash.uchicago.edu>
Message-ID: <48D13F9B.2040606@ucolick.org>

Updating the energy works splendidly. Thanks for your help guys!

Klaus Weide wrote:
> On Wed, 17 Sep 2008, James Guillochon wrote:
>
>> OK, I will give that a try. Is there anything else I should be 
>> cautious about? Is the Driver_sourceTerms routine the appropriate 
>> place to do this sort of thing?
>
> James,
>
> In the FLASH3 release, the Driver_sourceTerms implementation
> calls Stir.  The release also contains a Stir.F90 which modifies
> velocity components and adjusts energy.  You should be able to use
> that as a template.
>
> Klaus
>
> !DSPAM:10135,48d103e324268307041292!
>


From tplewa at fsu.edu  Wed Sep 17 12:56:00 2008
From: tplewa at fsu.edu (Tomasz Plewa)
Date: Wed, 17 Sep 2008 13:56:00 -0400
Subject: [FLASH-USERS] Altering Velocity Causes Anomalous Pressure
In-Reply-To: <48D13F9B.2040606@ucolick.org>
References: <48D0FB0D.8020107@ucolick.org> <48D0FD13.6080404@fsu.edu>
	<48D0FF0F.2040002@ucolick.org>
	<Pine.LNX.4.64.0809170815440.9831@flash.uchicago.edu>
	<48D13F9B.2040606@ucolick.org>
Message-ID: <48D144B0.4000607@fsu.edu>

An HTML attachment was scrubbed...
URL: http://flash.uchicago.edu/pipermail/flash-users/attachments/20080917/a449100e/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tplewa.vcf
Type: text/x-vcard
Size: 338 bytes
Desc: not available
Url : http://flash.uchicago.edu/pipermail/flash-users/attachments/20080917/a449100e/attachment.vcf 

From seyit at astro.rug.nl  Thu Sep 18 10:57:09 2008
From: seyit at astro.rug.nl (Seyit Hocuk)
Date: Thu, 18 Sep 2008 17:57:09 +0200
Subject: [FLASH-USERS] V-cycle not converging
Message-ID: <48D27A55.2090005@astro.rug.nl>

Hi,

In some of my simulations after some time into the simulation, I get a 
lot! of V-cycle warnings. What is the best way to avoid these and how 
bad are these warnings. I mean should I restart simulations or can I 
waive this warning.

Is changing "mgrid_max_residual_norm" a good option? Or should I use 
better optimizations. At the moment I am not using optimizations, but I 
noticed that using -03 reduced these warnings. How can I avoid them.

I bet you all will say that FLASH3 will solve my problems :)

Thanks,
Seyit


From tplewa at fsu.edu  Thu Sep 18 12:57:04 2008
From: tplewa at fsu.edu (Tomasz Plewa)
Date: Thu, 18 Sep 2008 13:57:04 -0400
Subject: [FLASH-USERS] V-cycle not converging
In-Reply-To: <48D27A55.2090005@astro.rug.nl>
References: <48D27A55.2090005@astro.rug.nl>
Message-ID: <48D29670.3020901@fsu.edu>

Seyit -

Moving to FLASH3 will potentially offer you more support. It does not 
guarantee that your problem will be automatically solved. Well, in 
general nothing can be taken for granted. But in this particular case, 
we have seen problems with FLASH2 multigrid that migrated to FLASH3. As 
I said, no guarantee (but still worth trying).

By the way, can you remind this audience what you are missing from FLASH2?

Tomek
--
Seyit Hocuk wrote:
> Hi,
>
> In some of my simulations after some time into the simulation, I get a 
> lot! of V-cycle warnings. What is the best way to avoid these and how 
> bad are these warnings. I mean should I restart simulations or can I 
> waive this warning.
>
> Is changing "mgrid_max_residual_norm" a good option? Or should I use 
> better optimizations. At the moment I am not using optimizations, but I 
> noticed that using -03 reduced these warnings. How can I avoid them.
>
> I bet you all will say that FLASH3 will solve my problems :)
>
> Thanks,
> Seyit
>
>   
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tplewa.vcf
Type: text/x-vcard
Size: 338 bytes
Desc: not available
Url : http://flash.uchicago.edu/pipermail/flash-users/attachments/20080918/3f49aed1/attachment.vcf 

From seyit at astro.rug.nl  Thu Sep 18 16:27:13 2008
From: seyit at astro.rug.nl (seyit)
Date: Thu, 18 Sep 2008 23:27:13 +0200
Subject: [FLASH-USERS] V-cycle not converging
In-Reply-To: <48D29670.3020901@fsu.edu>
References: <48D27A55.2090005@astro.rug.nl> <48D29670.3020901@fsu.edu>
Message-ID: <0c1b3cd3effa01f6baee653de33030cf@astro.rug.nl>

Tomek,

> By the way, can you remind this audience what you are missing from
FLASH2?

I think you mean at which part of the migration I have difficulties
switching to FLASH3? It has been some while now, but the last thing that I
did together with a colleague was solving some problems. I think the only
place we were stuck was trying to implement eos (eos1d in FLASH2.5). But I
will work on that after I finish my article with the results of FLASH2.5,
which are almost finished btw.

Anyway, could anyone answer the two "simple" questions I asked earlier?

1) Is this warning something bad?
2) would reducing mgrid_max_residual_norm (or using -O3 optimization) help?

Kind Regards,
Seyit

PS: have I mentioned how bad ifort 8 is?... I guess I have. I was reminded
of that again today, when I noticed yet again that that compiler messed up
some results.




On Thu, 18 Sep 2008 13:57:04 -0400, Tomasz Plewa <tplewa at fsu.edu> wrote:
> Seyit -
> 
> Moving to FLASH3 will potentially offer you more support. It does not
> guarantee that your problem will be automatically solved. Well, in
> general nothing can be taken for granted. But in this particular case,
> we have seen problems with FLASH2 multigrid that migrated to FLASH3. As
> I said, no guarantee (but still worth trying).
> 
> By the way, can you remind this audience what you are missing from
FLASH2?
> 
> Tomek
> --
> Seyit Hocuk wrote:
>> Hi,
>>
>> In some of my simulations after some time into the simulation, I get a
>> lot! of V-cycle warnings. What is the best way to avoid these and how
>> bad are these warnings. I mean should I restart simulations or can I
>> waive this warning.
>>
>> Is changing "mgrid_max_residual_norm" a good option? Or should I use
>> better optimizations. At the moment I am not using optimizations, but I
>> noticed that using -03 reduced these warnings. How can I avoid them.
>>
>> I bet you all will say that FLASH3 will solve my problems :)
>>
>> Thanks,
>> Seyit
>>
>>



From tplewa at fsu.edu  Thu Sep 18 16:30:01 2008
From: tplewa at fsu.edu (Tomasz Plewa)
Date: Thu, 18 Sep 2008 17:30:01 -0400
Subject: [FLASH-USERS] V-cycle not converging
In-Reply-To: <0c1b3cd3effa01f6baee653de33030cf@astro.rug.nl>
References: <48D27A55.2090005@astro.rug.nl> <48D29670.3020901@fsu.edu>
	<0c1b3cd3effa01f6baee653de33030cf@astro.rug.nl>
Message-ID: <48D2C859.1090901@fsu.edu>


>
> I think you mean at which part of the migration I have difficulties
> switching to FLASH3? It has been some while now, but the last thing that I
> did together with a colleague was solving some problems. I think the only
> place we were stuck was trying to implement eos (eos1d in FLASH2.5). But I
> will work on that after I finish my article with the results of FLASH2.5,
> which are almost finished btw.
>   
Good to hear, Seyit. And coming back to the eos problem might be for the 
best.

Good luck -

Tomek
--

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

From gawrysz at camk.edu.pl  Fri Sep 19 01:25:09 2008
From: gawrysz at camk.edu.pl (Artur Gawryszczak)
Date: Fri, 19 Sep 2008 08:25:09 +0200
Subject: [FLASH-USERS] V-cycle not converging
In-Reply-To: <0c1b3cd3effa01f6baee653de33030cf@astro.rug.nl>
References: <48D27A55.2090005@astro.rug.nl> <48D29670.3020901@fsu.edu>
	<0c1b3cd3effa01f6baee653de33030cf@astro.rug.nl>
Message-ID: <200809190825.10323@phoenix.camk.edu.pl>

On czwartek, 18 wrze?nia 2008, seyit wrote:
> 1) Is this warning something bad?

It depends on what was its cause. You may set mgrid_print_norm to .true. to 
see how many V-cycles are taken and how the convergence ratio changes. You 
may also want to inspect mg_unk array (mgw[1-5] fields in Flash 2.3 and 
earlier) to find where residuals remain uncorrected.

What boundary conditions do you use for gravity? For "isolated" BC it may 
happen that increase of mgrid_max_iter_change will help.

Another possibility is a defect of grid structure with a two refinement level 
difference across a corner or edge of the blocks. It occurs rarely when both 
refinement and derefinement of blocks takes place. Unfortunately I haven't 
any simple model that reproduces this problem. If this occured in your 
simulation you may expect defect in potential field located at grid fault 
(something like cosmic string ;-) ). It has usually magnitude of order of 1% 
or less, related to the correct field (an example or residual: 
http://users.camk.edu.pl/gawrysz/badrefinement.png), so it is possible that 
your simulations aren't much affected. You may also reduce mgrid_max_vcycles 
from the default value (100) to what is really needed (typically 10-15) to 
save some CPU time in some cases.

The change from mgw[1-5] fields in unk array to mg_unk array introduced in 
Flash 2.4 also reduced convergence ratio in multigrid solver, which 
indicates possible bug in guardcell communication. I haven't investigated it 
much - I just reverted from use of mg_unk to mgw[1-5] in unk.

If you plan to use multigrid solver in future I recommend you to switch to 
Flash 3.0 - the implementation of multigrid there is faster and better than 
in Flash 2.x.

> 2) would reducing mgrid_max_residual_norm (or using -O3 optimization)
> help?

It may hide the problem and will degrade quality of solution.

> PS: have I mentioned how bad ifort 8 is?... I guess I have. I was reminded
> of that again today, when I noticed yet again that that compiler messed up
> some results.

For me version 7 was unusable, 8 behaved suspiciously, 9 seemed to be usable 
until I run into some compiler bugs that messed up MPI communication, now I 
hope that 10.1 works well. In general Intel compilers are good because they 
produce fast executable but it is good to use other compilers and compare 
results from time to time.

-- 
Cheers,
        Artur


From seyit at astro.rug.nl  Fri Sep 19 04:31:00 2008
From: seyit at astro.rug.nl (Seyit Hocuk)
Date: Fri, 19 Sep 2008 11:31:00 +0200
Subject: [FLASH-USERS] V-cycle not converging
In-Reply-To: <200809190825.10323@phoenix.camk.edu.pl>
References: <48D27A55.2090005@astro.rug.nl> <48D29670.3020901@fsu.edu>
	<0c1b3cd3effa01f6baee653de33030cf@astro.rug.nl>
	<200809190825.10323@phoenix.camk.edu.pl>
Message-ID: <48D37154.6090203@astro.rug.nl>

Thanks Artur,

Your mail explained a lot to me.

Another possibility is a defect of grid structure with a two refinement level 
difference across a corner or edge of the blocks. It occurs rarely when both 
refinement and derefinement of blocks takes place.


That makes a lot of sense to me, because I may derefine very 
aggressively. I'm gonna check that.

If you plan to use multigrid solver in future I recommend you to switch to 
Flash 3.0 - the implementation of multigrid there is faster and better than 
in Flash 2.x.


I have to mention that I did a basic and a simple jeans and sedov test 
comparing flash 2.5 and 3.0. Flash3 was slower in finishing the 
simulations. I did assume that both the standard setups and parameters 
stayed the same.

For me version 7 was unusable, 8 behaved suspiciously, 9 seemed to be usable 
until I run into some compiler bugs that messed up MPI communication, now I 
hope that 10.1 works well. In general Intel compilers are good because they 
produce fast executable but it is good to use other compilers and compare 
results from time to time.


Glad to hear that I am not the only one who had bad experiences with 
older versions of ifort. Ifort 10 seems to work good though.


Thanks again Artur.

Seyit




Artur Gawryszczak wrote:
> On czwartek, 18 wrze?nia 2008, seyit wrote:
>   
>> 1) Is this warning something bad?
>>     
>
> It depends on what was its cause. You may set mgrid_print_norm to .true. to 
> see how many V-cycles are taken and how the convergence ratio changes. You 
> may also want to inspect mg_unk array (mgw[1-5] fields in Flash 2.3 and 
> earlier) to find where residuals remain uncorrected.
>
> What boundary conditions do you use for gravity? For "isolated" BC it may 
> happen that increase of mgrid_max_iter_change will help.
>
> Another possibility is a defect of grid structure with a two refinement level 
> difference across a corner or edge of the blocks. It occurs rarely when both 
> refinement and derefinement of blocks takes place. Unfortunately I haven't 
> any simple model that reproduces this problem. If this occured in your 
> simulation you may expect defect in potential field located at grid fault 
> (something like cosmic string ;-) ). It has usually magnitude of order of 1% 
> or less, related to the correct field (an example or residual: 
> http://users.camk.edu.pl/gawrysz/badrefinement.png), so it is possible that 
> your simulations aren't much affected. You may also reduce mgrid_max_vcycles 
> from the default value (100) to what is really needed (typically 10-15) to 
> save some CPU time in some cases.
>
> The change from mgw[1-5] fields in unk array to mg_unk array introduced in 
> Flash 2.4 also reduced convergence ratio in multigrid solver, which 
> indicates possible bug in guardcell communication. I haven't investigated it 
> much - I just reverted from use of mg_unk to mgw[1-5] in unk.
>
> If you plan to use multigrid solver in future I recommend you to switch to 
> Flash 3.0 - the implementation of multigrid there is faster and better than 
> in Flash 2.x.
>
>   
>> 2) would reducing mgrid_max_residual_norm (or using -O3 optimization)
>> help?
>>     
>
> It may hide the problem and will degrade quality of solution.
>
>   
>> PS: have I mentioned how bad ifort 8 is?... I guess I have. I was reminded
>> of that again today, when I noticed yet again that that compiler messed up
>> some results.
>>     
>
> For me version 7 was unusable, 8 behaved suspiciously, 9 seemed to be usable 
> until I run into some compiler bugs that messed up MPI communication, now I 
> hope that 10.1 works well. In general Intel compilers are good because they 
> produce fast executable but it is good to use other compilers and compare 
> results from time to time.
>
>