From cmalone at scotty.ess.sunysb.edu Thu Oct 4 10:28:07 2007 From: cmalone at scotty.ess.sunysb.edu (Chris Malone) Date: Thu, 4 Oct 2007 11:28:07 -0400 (EDT) Subject: [FLASH-BUGS] Bug in iso7 reaction network Message-ID: I was recently trying to modify the iso7 reaction network when I discovered a bug in the calculation of the dense jacobian element pertaining to the triple alpha reaction. When calculating the change in composition we have: dydt(ihe4) = -3.0e0 * y(ihe4) * y(ihe4) * y(ihe4) * ratdum(ir3a) + ... The -3.0e0 is from the fact that we are losing 3 helium nuclei per triple alpha reaction and the reaction rate has already been divided by 3! = 6 to prevent double counting. Now to calculte the dense jacobian matrix element, dfdy(ihe4, ihe4), in diso7 (in FLASH version 2) we should simply take the above expression and differentiate with respect to helium composition giving: dfdy(ihe4, ihe4) = -9.0e0 * y(ihe4) * y(ihe4) * ratdum(ir3a) + ... However, in the FLASH implementation of iso7 the coefficient is -6.0e0 not -9.0e0. I brought this to the attention of Frank Timmes and he said indeed it was a bug and that he was not suprised that the bug propagated through to FLASH because the paper he wrote that describes this reaction network also had the error. Frank also commented that the bug does not affect the results of the calculation for the change in helium abundance but rather the efficiency of the algorithm. Chris From lynnreid at flash.uchicago.edu Fri Oct 5 09:53:38 2007 From: lynnreid at flash.uchicago.edu (Lynn Reid) Date: Fri, 05 Oct 2007 09:53:38 -0500 Subject: [FLASH-BUGS] Bug in iso7 reaction network In-Reply-To: References: Message-ID: <47064FF2.9010702@flash.uchicago.edu> Chris: Many thanks for your email with the astute discovery of a bug in the iso7 network. I have changed the source code in subroutine diso7 in FLASH2/source/source_terms/burn/iso7/net.F90, and made an equivalent change in FLASH3's version at FLASH3/source/physics/sourceTerms/Burn/BurnMain/nuclearBurn/iso7/bn_networkDenseJakob.F90. I have noted in the source code your squashing of the bug, and added your email below to the change logs for both FLASH2 and FLASH3. Best wishes, Lynn Reid Chris Malone wrote: > > I was recently trying to modify the iso7 reaction network when I > discovered a bug in the calculation of the dense jacobian element > pertaining to the triple alpha reaction. When calculating the change > in composition we have: > > dydt(ihe4) = -3.0e0 * y(ihe4) * y(ihe4) * y(ihe4) * ratdum(ir3a) + ... > > The -3.0e0 is from the fact that we are losing 3 helium nuclei per > triple alpha reaction and the reaction rate has already been divided > by 3! = 6 to prevent double counting. Now to calculte the dense > jacobian matrix element, dfdy(ihe4, ihe4), in diso7 (in FLASH version > 2) we should simply take the above expression and differentiate with > respect to helium composition giving: > > dfdy(ihe4, ihe4) = -9.0e0 * y(ihe4) * y(ihe4) * ratdum(ir3a) + ... > > However, in the FLASH implementation of iso7 the coefficient is -6.0e0 > not -9.0e0. I brought this to the attention of Frank Timmes and he > said indeed it was a bug and that he was not suprised that the bug > propagated through to FLASH because the paper he wrote that describes > this reaction network also had the error. > > Frank also commented that the bug does not affect the results of the > calculation for the change in helium abundance but rather the > efficiency of the algorithm. > > Chris -- Dr. Lynn B. Reid, Scientific Programmer ASC Center for Astrophysical Thermonuclear Flashes The University of Chicago 5640 S. Ellis, RI 473; Chicago, IL 60637 USA +1-773-702-0624 phone From smc at astro.as.utexas.edu Mon Oct 29 11:06:32 2007 From: smc at astro.as.utexas.edu (Sean Couch) Date: Mon, 29 Oct 2007 11:06:32 -0500 Subject: [FLASH-BUGS] Multipole gravity broken in parallel? Message-ID: <2AB069E7-F53C-4D78-BEE2-9C697A88D771@astro.as.utexas.edu> Hi, I am having trouble implementing the multipole gravity solver on multiple processors. I am using a 2D spherical grid with periodic boundary conditions in theta and outflow BCs in radius. I am using isolated grav BCs. I have tested the setup on a single processor and it works fine. The error seems to be that initial values for the gravitational potential are not calculated correctly. The grav potential will typically be accurate up to a certain radius, after which the value of the potential becomes negative infinity. This 'cut-off' radius is number-of-processors dependent. Generally increasing the number of processors increases the cut-off radius, however using 128 processors still gives the same error, regardless of domain size! This problem with the potential immediately leads to a non-convergence in the Riemann solver on the first time step. I am running Flash 2.5 on an Intel Linux cluster using Intel compilers. I have had plenty of success with the identical setup, neglecting self-gravity, on numerous processors. Also, point mass gravity works without a hitch. I have also tried the sedov +selfgravity problem, which uses the multipole solver in spherical coordinates, and I get the very same error. I would try the multgrid solver, but that is not supported for spherical coordinates. Any help would be very much appreciated, Sean