From klaus at flash.uchicago.edu Thu Jul 2 18:46:06 2009 From: klaus at flash.uchicago.edu (Klaus Weide) Date: Thu, 2 Jul 2009 18:46:06 -0500 (CDT) Subject: [FLASH-USERS] FLASH3.2 Release Message-ID: The Flash Center is pleased to announce the release of the next version of the FLASH code, version 3.2. FLASH 3.2 includes several new features and resolves many bugs found in previous releases up to 3.1.1. Capabilities added since the FLASH3.1.1 release include: * An Unsplit Hydrodynamics Solver. * Ability to apply the equation of state to face and scratch variables. There are two new interfaces in the Eos unit to get and put data from the Grid data structures which allow the Eos unit to operate on all supported Grid data structures. The setup script is also enhanced to be able to determine mapping between Grid data structures, and the corresponding indices into the eosData array used by the Eos_wrapped interface. This capability has been well tested for the cell centered variables, but has had limited testing with face and scratch variables. * Enhancement in the IO unit to the collective mode of operation in HDF5. Please note that the collective mode is known to be unreliable on the BG/P platform when used for writing the metadata describing Grid or Particles variables. This is an issue with the MPI-IO implementation on the platform, IBM is aware of it. * Significant performance improvement in the algorithm to map paramesh grid to a uniform grid which, when coupled with the multigrid solver, permits the coarse grid exact solve at higher resolution in parallel. * A new add-on unit to compute radiative transfer using Hybrid characteristics is available upon request from Natalie Hinkel at Arizona State University. The algorithm was originally developed by Erik-Jan Rijkhorst, and has since been translated to FLASH3. * Added logic for limiting maximum refinement, based on time or on distance from a center (currently only for Cartesian and 2D-cylindrical geometries). Original contributions by Sean Couch. New runtime parameters added for this. * Fixes and improvements in Config file parsing: Now can use CONSTANT keyword to make a runtime parameter as unmodifiable (and several code units now use this); Now can use a range like "[ TINY ... ]" to indicate that a runtime parameter must be positive. * A longer list of changes is contained in the User's Guide in section 1.2, What's New in This Release. Issues that have become known since the FLASH3.1.1 release and have been fixed in FLASH 3.2 include: * A bug in the Driver unit that could leave the mesh in a non-deterministic state upon initialization when using active particles. * In FLASH3.1.1 we gave up on assigning unique MPI tags to messages in various places, since this would lead to tag values exceeding the allowed maximum of at least one MPI implementation. The change had the undesirable effect of causing deadlocks in some tests, which we have not been able to fully analyze. So for Paramesh4.0, we are reverting back to the method for assigning message tags that was used before FLASH3.1.1. (by defining PM_UNIQUE_MPI_TAGS) * Removed a directional bias in Hydro PPM solver when "hybrid_riemann" was used: decision for when to use the alternative Riemann solver should depend on the cells left and right of a zone interface, not just the right one. * Many more issues that have been resolved are listed at http://flash.uchicago.edu/website/codesupport/knownIssues.html . Improvements and bug fixes since FLASH 3.1 that were already part of release FLASH 3.1.1a include - * Fixed mapping of active particles to the mesh. The problem was that the mapping routines used some data from Paramesh which wasn't yet updated, resulting in potentially undefined behavior. The solution was to introduce a routine named GridMain/paramesh/paramesh4/gr_ensureValidNeighborInfo.F90 which ensures data is valid before we query internal PARAMESH data structures. (Already in FLASH 3.1.1.) * Fixed an additional bug in the same section of the code when calculating the block/processor/corner IDs of neighboring blocks when a block face touches 4 neighbors at a higher refinement level (3D simulations only). (Already in FLASH 3.1.1.) * Now fidlr can read PnetCDF output files without failing. * Bugs in implementations of Balsara's algorithm for prolonging divergence-free face-centered magnetic fields have been fixed. * A redundancy for keeping both magnetic resistivity and magnetic viscosity has been removed in materialProperties/MagneticResistivity unit. Only magnetic resistivity is being used with proper scalings in this release. * There was a problem with overflowing MPI tag values in PARAMESH when using certain MPI implementations. This has now been resolved in pm4dev. The old behaviour of assigning each MPI message a unique tag ID can be restored by defining PM_UNIQUE_MPI_TAGS pre-processor definition in setup script call. * There was extremely poor performance when reading particle data from a checkpoint file on BG/P. We revert to the old contiguous particle attribute read of FLASH 3.0 when particle fields are the same in the checkpoint file and flash3 binary to improve performance. * Introduced an alternative implementation of PFFT routines which map FLASH grid data to a pencil grid (Grid/GridSolvers/Pfft/MeshReconfiguration/PtToPt). This implemetation uses less memory than the FLASH 3.1 implementation (Grid/GridSolvers/Pfft/MeshReconfiguration/Collective). The PtToPt routines make use of a file named (flashUtilities/datastructures/linkedlist/ut_listMethods.includeF90) which can be included in any Fortran module to construct a linked list of user-specified node types. The release is available at: http://flash.uchicago.edu/website/download/ A stripped down version of FLASH3 that may be downloaded without a license is also available at http://flash.uchicago.edu/website/codesupport/ This version is essentially the FLASH framework without any implementations. The 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. FLASH Code Group From flash-users at flash.uchicago.edu Thu Jul 9 00:12:30 2009 From: flash-users at flash.uchicago.edu (#1 Internet Online Drugstore) Date: Thu, 9 Jul 2009 00:12:30 -0500 (CDT) Subject: [FLASH-USERS] [SPAM] USA Discount 70% OFF on Pfizer! Message-ID: <20090709101238.2550.qmail@dsl78.160-33702.ttnet.net.tr> An HTML attachment was scrubbed... URL: http://flash.uchicago.edu/pipermail/flash-users/attachments/20090709/9d0a8e60/attachment.html From Daniel.Pfenniger at obs.unige.ch Thu Jul 9 11:26:25 2009 From: Daniel.Pfenniger at obs.unige.ch (Daniel Pfenniger) Date: Thu, 09 Jul 2009 18:26:25 +0200 Subject: [FLASH-USERS] Pancake with hydro Message-ID: <4A561A31.7050402@obs.unige.ch> Hello, I try to reproduce the pancake example (22.4.2 in the UG) for Flash 3.2. With the default configuration it seems that the baryons are not really included because the baryon density (variable dens) is 0, while OmegaBaryon is set to 0.15. The particles are there. My aim is to include also hydro, do I miss something? Dan From cdaley at flash.uchicago.edu Tue Jul 14 07:53:12 2009 From: cdaley at flash.uchicago.edu (Chris Daley) Date: Tue, 14 Jul 2009 07:53:12 -0500 Subject: [FLASH-USERS] Pancake with hydro In-Reply-To: <4A561A31.7050402@obs.unige.ch> References: <4A561A31.7050402@obs.unige.ch> Message-ID: <4A5C7FB8.7090404@flash.uchicago.edu> The default pancake setup only includes particles. You can add "--with-unit=physics/Hydro" to the setup line to include hydro. e.g. ./setup Pancake -auto --with-unit=physics/Hydro -objdir=pancake_with_hydro -parfile=test_paramesh_2d.par Regards, Chris Daniel Pfenniger wrote: > Hello, > > I try to reproduce the pancake example (22.4.2 in the UG) for Flash 3.2. > With the default configuration it seems that the baryons > are not really included because the baryon density (variable dens) is 0, > while OmegaBaryon is set to 0.15. The particles are there. > > My aim is to include also hydro, do I miss something? > > Dan > > From Aaron.Jackson at stonybrook.edu Tue Jul 28 12:19:43 2009 From: Aaron.Jackson at stonybrook.edu (Aaron Jackson) Date: Tue, 28 Jul 2009 13:19:43 -0400 Subject: [FLASH-USERS] Bounds-checking fails on IBM BG/L Message-ID: <00ad01ca0fa7$991362a0$cb3a27e0$%Jackson@stonybrook.edu> Hello FLASH users, I'm getting an error running my simulation in which the error output says things like: Glibc detected : 0xmalloc(): memory corruption0f749020: 0x *** : 0xfree(): invalid pointer10780c70: 0x *** : 0xdouble free or corruption (out)0e11b930: 0x *** I'm attempting to compile the code with bounds-checking enabled; however, I get the following error message in a subroutine which I'm not concerned about. The code will not continue compiling past this point where I need it to analyze my subroutines. /bgl/BlueLight/ppcfloor/bglsys/bin/mpixlf90 -g -C -qintsize=4 -qrealsize=8 -qfixed -qnosave -c -qsuffix=cpp=F -qarch=440 -qtune=440 -qmaxmem=131072 -qstrict -qsuffix=f=F90:cpp=F90 -qfree=f90 -WF,-DMAXBLOCKS=500 -WF,-DNXB=16 -WF,-DNYB=16 -WF,-DNZB=1 -WF,-DN_DIM=2 Grid_getBlkData.F90 "Grid_getBlkData.F90", line 483.28: 1516-152 (S) Zero-sized arrays must not be subscripted. 1501-511 Compilation failed for file Grid_getBlkData.F90. make: *** [Grid_getBlkData.o] Error 1 Does anyone know of a way to get around this or fix this problem so that I can compile with bounds-checking? I'm using the IBM BlueGene/L with the XL Fortran 90 compilers. Thanks, Aaron Jackson -------------- next part -------------- An HTML attachment was scrubbed... URL: http://flash.uchicago.edu/pipermail/flash-users/attachments/20090728/68f91ef2/attachment.html From klaus at flash.uchicago.edu Tue Jul 28 17:11:47 2009 From: klaus at flash.uchicago.edu (Klaus Weide) Date: Tue, 28 Jul 2009 17:11:47 -0500 (CDT) Subject: [FLASH-USERS] Bounds-checking fails on IBM BG/L In-Reply-To: <00ad01ca0fa7$991362a0$cb3a27e0$%Jackson@stonybrook.edu> References: <00ad01ca0fa7$991362a0$cb3a27e0$%Jackson@stonybrook.edu> Message-ID: On Tue, 28 Jul 2009, Aaron Jackson wrote: > /bgl/BlueLight/ppcfloor/bglsys/bin/mpixlf90 -g -C -qintsize=4 -qrealsize=8 > -qfixed -qnosave -c -qsuffix=cpp=F -qarch=440 -qtune=440 -qmaxmem=131072 > -qstrict -qsuffix=f=F90:cpp=F90 -qfree=f90 -WF,-DMAXBLOCKS=500 -WF,-DNXB=16 > -WF,-DNYB=16 -WF,-DNZB=1 -WF,-DN_DIM=2 Grid_getBlkData.F90 > > "Grid_getBlkData.F90", line 483.28: 1516-152 (S) Zero-sized arrays must not > be subscripted. > > 1501-511 Compilation failed for file Grid_getBlkData.F90. I tried this on Intrepid (BG/P), the file compiled fine there. (Sorry.) Klaus From cdaley at flash.uchicago.edu Tue Jul 28 20:14:27 2009 From: cdaley at flash.uchicago.edu (Christopher Daley) Date: Tue, 28 Jul 2009 20:14:27 -0500 Subject: [FLASH-USERS] Bounds-checking fails on IBM BG/L In-Reply-To: <00ad01ca0fa7$991362a0$cb3a27e0$%Jackson@stonybrook.edu> References: <00ad01ca0fa7$991362a0$cb3a27e0$%Jackson@stonybrook.edu> Message-ID: <20090729011301.GA32213@cetus.asci.uchicago.edu> Hi Aaron, > > Does anyone know of a way to get around this or fix this problem so that I > can compile with bounds-checking? > I have had this compilation failure before. It is a problem with the IBM compilers as zero-sized arrays are allowed by the Fortran standard. It is happening because your application does not use scratch variables and so a dimension of "scratch" array (unused in your application) is zero. In the past I have added extra rules to Makefile.h to compile the affected files according to FFLAGS_TEST options rather than FFLAGS_DEBUG options (my FFLAGS_DEBUG had -C option and FFLAGS_TEST did not), e.g. Grid_getBlkData.o : Grid_getBlkData.F90 ${FCOMP} ${FFLAGS_TEST} ${F90FLAGS} ${FDEFINES} $< Grid_getPlaneData.o : Grid_getPlaneData.F90 ${FCOMP} ${FFLAGS_TEST} ${F90FLAGS} ${FDEFINES} $< Grid_getPointData.o : Grid_getPointData.F90 ${FCOMP} ${FFLAGS_TEST} ${F90FLAGS} ${FDEFINES} $< Grid_getRowData.o : Grid_getRowData.F90 ${FCOMP} ${FFLAGS_TEST} ${F90FLAGS} ${FDEFINES} $< Grid_putBlkData.o : Grid_putBlkData.F90 ${FCOMP} ${FFLAGS_TEST} ${F90FLAGS} ${FDEFINES} $< Grid_putPlaneData.o : Grid_putPlaneData.F90 ${FCOMP} ${FFLAGS_TEST} ${F90FLAGS} ${FDEFINES} $< Grid_putPointData.o : Grid_putPointData.F90 ${FCOMP} ${FFLAGS_TEST} ${F90FLAGS} ${FDEFINES} $< Grid_putRowData.o : Grid_putRowData.F90 ${FCOMP} ${FFLAGS_TEST} ${F90FLAGS} ${FDEFINES} $< However, thinking about it, a quick fix that should work is to change NSCRATCH_GRID_VARS from 0 to 1 in Flash.h. For Blue Gene systems, you may find it helpful to add "--env BG_COREDUMPONERROR=1" option to qsub. When your application encounters the error it will dump a whole bunch of core files that can be analysed using coreprocessor.pl tool. Regards, Chris