From nttaylor at flash.uchicago.edu Fri Mar 2 18:50:44 2007 From: nttaylor at flash.uchicago.edu (Noel Taylor) Date: Fri, 2 Mar 2007 18:50:44 -0600 (CST) Subject: [FLASH-USERS] FLASH3 beta release announcement Message-ID: The Flash Code group is pleased to announce the beta release of the next major version of the FLASH code, version 3.0. Added capabilities include: * A new, directionally unsplit, staggered mesh MHD solver that works in one and two dimensions. * Two new nuclear burning networks (the alpha release had only one) * Two new sets of algorithms for moving Lagrangian tracers in AMR. The alpha release supported only the Uniform Grid. Additionally, the method for initializing particle-positions based upon the density distribution has been imported from FLASH2. * A new unsplit timestepping method to handle the staggered mesh MHD unit. * An improved self gravity solver using multipole method that allows users to optimize by controlling the amount of subsampling at runtime. * A unit test based upon the Maclaurin's spheroid problem. * In the logfile, a more extensive summary of code performance at the end of the run. It includes maximum and minimum time on any processor for each code unit. The following improvements have also been made to the Grid unit: * Full support for face centered variables, and domains with obstacles. * A cleaner and more consistent way to handle conversion between conservative and primitive variables based upon classification of variables at configuration time. * Support for the masked guardcell fill provided in Paramesh 3. * A new subunit called "GridSolvers" where solvers such as multigrid etc. will have their grid-specific implementations. Currently the only solver in this subunit is the Multipole solver. We have also included the pre-release version of Paramesh 3 with improved communication buffer management. The beta release is available for download with a license agreement at: http://flash.uchicago.edu/website/download/home.html/ A stripped down version of FLASH3 that may be downloaded without a license is also available at the same location. This version is essentially the FLASH framework without any implementations. Additionally, the FLASH testing software FlashTest, which became available with the alpha release, continues to be available for download at: http://flash.uchicago.edu/website/codesupport/ Many, but not all parts of FLASH3 are backwards-compatible with FLASH2. The Flash code group has written extensive documentation detailing how to make the transition from FLASH2 to FLASH3 as smooth as possible. The user should look to: http://flash.uchicago.edu/website/codesupport/ for help on transitioning to FLASH3. For these early releases, all the documentation will be included on the website rather than in the tarball. The website will also contain other documentation including a user's guide and a developer's section. A new feature in FLASH3 documentation is the online description of the public interface routines to various code units. Development of the FLASH Code was funded by the DOE-supported ASC/Alliance Center for Astrophysical Thermonuclear Flashes. We acknowledge support received from Lawrence Livermore National Laboratory and the University of Chicago. All publications resulting from the use of the FLASH Code must acknowledge the ASC/Alliance Center for Astrophysical Thermonuclear Flashes. Addition of the following text to the paper acknowledgments will be sufficient. "The software used in this work was in part developed by the DOE-supported ASC/Alliance Center for Astrophysical Thermonuclear Flashes at the University of Chicago." --Flash Code Group From e.roediger at iu-bremen.de Mon Mar 5 07:59:45 2007 From: e.roediger at iu-bremen.de (Dr. Elke Roediger) Date: Mon, 5 Mar 2007 14:59:45 +0100 (CET) Subject: [FLASH-USERS] memory overflow in AMR_RESTRICT_CC Message-ID: <2806.84.137.97.19.1173103185.squirrel@mail2web.iu-bremen.de> Hi everybody, I have a problem with memory overflow. The code is running happily for a while and then stops with the following error message: min_blocks 501 max_blocks 593 tot_blocks 17056 [AMR_RESTRICT_CC] ERROR: memory overflow, iopt=1: 1209 593 There is no other hint in either amr_log nor in the log-file. The code was compiled with maxblocks=1800, and I am sure that is has been running on the same machine with at least 1200 blocks per cpu. It seems to me that I am far away from having more than 1800 blocks per cpu at the moment. Judging from what I could understand from a short look at the routine AMR_RESTRICT_CC, this routine counts some kind of child blocks or neighboring blocks (which makes the number 1209 in the error message), and those together with the 593 "real" blocks exceed the allowed 1800. That makes the code stop. I am running a simulation with 9 levels of refinement, where the highly refined region is very small, essentially it fits into one of the basic block's cells. Does somebody know a better explanation for what is going on, and -even more important- a workaround for this problem? Thanks a lot, Elke Roediger ---------------------------- Dr. Elke Roediger Astrophysics Group Jacobs University Bremen Telephone: +49 421 200-3192 Fax: +49 421 200-3229 Office: Research III, Room 124b Mailing Address: P. O. Box 750 561 28725 Bremen Germany From bernalcg at astroscu.unam.mx Tue Mar 13 13:53:10 2007 From: bernalcg at astroscu.unam.mx (Cristian Giovanny Bernal) Date: Tue, 13 Mar 2007 12:53:10 -0600 Subject: [FLASH-USERS] apple_mac_Flash... Message-ID: <20070313184909.M5257@astroscu.unam.mx> Hi All, I am considering buying Apple Mac PRO with two (2.66 GHz) dual-core Intel Xeon, 13 GB RAM. with the Intel Fortran compiler. The Flash Code (2.5 or 3.0 version) compiling and running in such platforms????? very thanks in advanced for the information. -- Instituto de Astronomia Universidad Nacional Autonoma de Mexico (UNAM) http://www.astroscu.unam.mx From bernalcg at astroscu.unam.mx Wed Mar 14 19:44:12 2007 From: bernalcg at astroscu.unam.mx (Cristian Giovanny Bernal) Date: Wed, 14 Mar 2007 18:44:12 -0600 Subject: [FLASH-USERS] Hydrostatic Boundary+Helmholtz eos+spherical geometry Message-ID: <20070315003417.M80566@astroscu.unam.mx> Hi all, I am simulating the accretion of an atmosphere onto compact object in spherical coordinates 2D (FLASH2.5). I am using HELMHOLTZ_EOS and I want to use a hydrostatic boundary condition in r_min(/ =0.0). Nevertheless, the code not run and produce a Helmeos routine error. However, with Reflecting and Outflow boundary conditions the simulation run any problem.... how I resolve this problem? The hydrostatic boundary condition work on spherical geometry + Helmholtz_eos? I think that the problem is the Helmholtz_EOS because the simulation work fine with EOS_gamma. some suggestion??? very thanks in advanced. -- Instituto de Astronomia Universidad Nacional Autonoma de Mexico (UNAM) http://www.astroscu.unam.mx From van at astro.ox.ac.uk Fri Mar 16 11:22:28 2007 From: van at astro.ox.ac.uk (Vincenzo Antonuccio) Date: Fri, 16 Mar 2007 16:22:28 +0000 Subject: [FLASH-USERS] A solution to the "MAXBLOCKS" problem Message-ID: <200703161622.28411.van@astro.ox.ac.uk> As some other FLASH 2.x users, I have also recently experienced the error in amr_redist arising from the unability to move blocks among different tasks. The suggested solution is often that of increasing the number of processors, or the MAXBLOCKS variable at setup. However, the jobs I am running are using 2D runs, with 24 processors and the average number of blocks per processor (task) never exceed 1000 blocks (in fact, its is much lesser). Yet, I was systematically running into this deadlock. The way out I have found has to do with the compiler options, not with FLASH (iI am using v. 2.5 for this run). I am running on a cluster of Opteron's, using MPICH2/mpichf90, which call ifort v. 9.1. When I degraded from an aggressive optimization (-O3) to -O2, the problem apparently disappeared. I guess that the reason is that, in order to increase performance, the compiler makes some tradeoff with memory occupation, possibly forcing lesser freedom to the code in allocating memory. In any case, now FLASH does not run anymore into error because of that. ****************************************** Vincenzo ANTONUCCIO-DELOGU Astrophysics, University of Oxford Denys Wilkinson Building Keble Road, Oxford OX1 3RH United Kingdom Room 555A, Beecroft Inst. for Particle Astrophysics Tlf.: +44-(0)1865 283019 Fax: +44-(0)1865-273390 e-mail: van at astro.ox.ac.uk 'Malheur a l'homme d'etude qui n'est d'aucune coterie, on lui reprochera jusqu'a de petits succes fort incertains, et la haute vertu triomphera en le volant.' Guai all'intellettuale che non appartiene a nessuna consorteria: gli sara' rimproverato ogni successo, anche il piu' incerto, e la virtu' trionfera' derubandolo. (Stendhal, Le Rouge et le Noir) From nttaylor at flash.uchicago.edu Fri Mar 2 18:50:44 2007 From: nttaylor at flash.uchicago.edu (Noel Taylor) Date: Fri, 2 Mar 2007 18:50:44 -0600 (CST) Subject: [FLASH-USERS] FLASH3 beta release announcement Message-ID: The Flash Code group is pleased to announce the beta release of the next major version of the FLASH code, version 3.0. Added capabilities include: * A new, directionally unsplit, staggered mesh MHD solver that works in one and two dimensions. * Two new nuclear burning networks (the alpha release had only one) * Two new sets of algorithms for moving Lagrangian tracers in AMR. The alpha release supported only the Uniform Grid. Additionally, the method for initializing particle-positions based upon the density distribution has been imported from FLASH2. * A new unsplit timestepping method to handle the staggered mesh MHD unit. * An improved self gravity solver using multipole method that allows users to optimize by controlling the amount of subsampling at runtime. * A unit test based upon the Maclaurin's spheroid problem. * In the logfile, a more extensive summary of code performance at the end of the run. It includes maximum and minimum time on any processor for each code unit. The following improvements have also been made to the Grid unit: * Full support for face centered variables, and domains with obstacles. * A cleaner and more consistent way to handle conversion between conservative and primitive variables based upon classification of variables at configuration time. * Support for the masked guardcell fill provided in Paramesh 3. * A new subunit called "GridSolvers" where solvers such as multigrid etc. will have their grid-specific implementations. Currently the only solver in this subunit is the Multipole solver. We have also included the pre-release version of Paramesh 3 with improved communication buffer management. The beta release is available for download with a license agreement at: http://flash.uchicago.edu/website/download/home.html/ A stripped down version of FLASH3 that may be downloaded without a license is also available at the same location. This version is essentially the FLASH framework without any implementations. Additionally, the FLASH testing software FlashTest, which became available with the alpha release, continues to be available for download at: http://flash.uchicago.edu/website/codesupport/ Many, but not all parts of FLASH3 are backwards-compatible with FLASH2. The Flash code group has written extensive documentation detailing how to make the transition from FLASH2 to FLASH3 as smooth as possible. The user should look to: http://flash.uchicago.edu/website/codesupport/ for help on transitioning to FLASH3. For these early releases, all the documentation will be included on the website rather than in the tarball. The website will also contain other documentation including a user's guide and a developer's section. A new feature in FLASH3 documentation is the online description of the public interface routines to various code units. Development of the FLASH Code was funded by the DOE-supported ASC/Alliance Center for Astrophysical Thermonuclear Flashes. We acknowledge support received from Lawrence Livermore National Laboratory and the University of Chicago. All publications resulting from the use of the FLASH Code must acknowledge the ASC/Alliance Center for Astrophysical Thermonuclear Flashes. Addition of the following text to the paper acknowledgments will be sufficient. "The software used in this work was in part developed by the DOE-supported ASC/Alliance Center for Astrophysical Thermonuclear Flashes at the University of Chicago." --Flash Code Group From e.roediger at iu-bremen.de Mon Mar 5 07:59:45 2007 From: e.roediger at iu-bremen.de (Dr. Elke Roediger) Date: Mon, 5 Mar 2007 14:59:45 +0100 (CET) Subject: [FLASH-USERS] memory overflow in AMR_RESTRICT_CC Message-ID: <2806.84.137.97.19.1173103185.squirrel@mail2web.iu-bremen.de> Hi everybody, I have a problem with memory overflow. The code is running happily for a while and then stops with the following error message: min_blocks 501 max_blocks 593 tot_blocks 17056 [AMR_RESTRICT_CC] ERROR: memory overflow, iopt=1: 1209 593 There is no other hint in either amr_log nor in the log-file. The code was compiled with maxblocks=1800, and I am sure that is has been running on the same machine with at least 1200 blocks per cpu. It seems to me that I am far away from having more than 1800 blocks per cpu at the moment. Judging from what I could understand from a short look at the routine AMR_RESTRICT_CC, this routine counts some kind of child blocks or neighboring blocks (which makes the number 1209 in the error message), and those together with the 593 "real" blocks exceed the allowed 1800. That makes the code stop. I am running a simulation with 9 levels of refinement, where the highly refined region is very small, essentially it fits into one of the basic block's cells. Does somebody know a better explanation for what is going on, and -even more important- a workaround for this problem? Thanks a lot, Elke Roediger ---------------------------- Dr. Elke Roediger Astrophysics Group Jacobs University Bremen Telephone: +49 421 200-3192 Fax: +49 421 200-3229 Office: Research III, Room 124b Mailing Address: P. O. Box 750 561 28725 Bremen Germany From bernalcg at astroscu.unam.mx Tue Mar 13 13:53:10 2007 From: bernalcg at astroscu.unam.mx (Cristian Giovanny Bernal) Date: Tue, 13 Mar 2007 12:53:10 -0600 Subject: [FLASH-USERS] apple_mac_Flash... Message-ID: <20070313184909.M5257@astroscu.unam.mx> Hi All, I am considering buying Apple Mac PRO with two (2.66 GHz) dual-core Intel Xeon, 13 GB RAM. with the Intel Fortran compiler. The Flash Code (2.5 or 3.0 version) compiling and running in such platforms????? very thanks in advanced for the information. -- Instituto de Astronomia Universidad Nacional Autonoma de Mexico (UNAM) http://www.astroscu.unam.mx From bernalcg at astroscu.unam.mx Wed Mar 14 19:44:12 2007 From: bernalcg at astroscu.unam.mx (Cristian Giovanny Bernal) Date: Wed, 14 Mar 2007 18:44:12 -0600 Subject: [FLASH-USERS] Hydrostatic Boundary+Helmholtz eos+spherical geometry Message-ID: <20070315003417.M80566@astroscu.unam.mx> Hi all, I am simulating the accretion of an atmosphere onto compact object in spherical coordinates 2D (FLASH2.5). I am using HELMHOLTZ_EOS and I want to use a hydrostatic boundary condition in r_min(/ =0.0). Nevertheless, the code not run and produce a Helmeos routine error. However, with Reflecting and Outflow boundary conditions the simulation run any problem.... how I resolve this problem? The hydrostatic boundary condition work on spherical geometry + Helmholtz_eos? I think that the problem is the Helmholtz_EOS because the simulation work fine with EOS_gamma. some suggestion??? very thanks in advanced. -- Instituto de Astronomia Universidad Nacional Autonoma de Mexico (UNAM) http://www.astroscu.unam.mx From van at astro.ox.ac.uk Fri Mar 16 11:22:28 2007 From: van at astro.ox.ac.uk (Vincenzo Antonuccio) Date: Fri, 16 Mar 2007 16:22:28 +0000 Subject: [FLASH-USERS] A solution to the "MAXBLOCKS" problem Message-ID: <200703161622.28411.van@astro.ox.ac.uk> As some other FLASH 2.x users, I have also recently experienced the error in amr_redist arising from the unability to move blocks among different tasks. The suggested solution is often that of increasing the number of processors, or the MAXBLOCKS variable at setup. However, the jobs I am running are using 2D runs, with 24 processors and the average number of blocks per processor (task) never exceed 1000 blocks (in fact, its is much lesser). Yet, I was systematically running into this deadlock. The way out I have found has to do with the compiler options, not with FLASH (iI am using v. 2.5 for this run). I am running on a cluster of Opteron's, using MPICH2/mpichf90, which call ifort v. 9.1. When I degraded from an aggressive optimization (-O3) to -O2, the problem apparently disappeared. I guess that the reason is that, in order to increase performance, the compiler makes some tradeoff with memory occupation, possibly forcing lesser freedom to the code in allocating memory. In any case, now FLASH does not run anymore into error because of that. ****************************************** Vincenzo ANTONUCCIO-DELOGU Astrophysics, University of Oxford Denys Wilkinson Building Keble Road, Oxford OX1 3RH United Kingdom Room 555A, Beecroft Inst. for Particle Astrophysics Tlf.: +44-(0)1865 283019 Fax: +44-(0)1865-273390 e-mail: van at astro.ox.ac.uk 'Malheur a l'homme d'etude qui n'est d'aucune coterie, on lui reprochera jusqu'a de petits succes fort incertains, et la haute vertu triomphera en le volant.' Guai all'intellettuale che non appartiene a nessuna consorteria: gli sara' rimproverato ogni successo, anche il piu' incerto, e la virtu' trionfera' derubandolo. (Stendhal, Le Rouge et le Noir)