[FLASH-USERS] Bug in 3T hy_uhd_DataReconstructNormalDir_MH.F90
Klaus Weide
klaus at flash.uchicago.edu
Mon May 9 14:42:11 EDT 2016
On Mon, 9 May 2016, Mark Richardson wrote:
> Hello,
>
> there appears to be a bug in hy_uhd_DataReconstructNormalDir_MH.F90, at
> least for the 3T case.
>
> For the MUSCL-Hancock case, korder is set to 1 in
> hy_uhd_dataReconstOneStep.F90, but in
> hy_uhd_DataReconstructNormalDir_MH.F90 at line 227 Data1D (which points to
> U(:,ix-korder:ix+korder,iy,iz) for the x sweep say, thus sizeof(Data1D) =
> NVAR * (2korder+1) = NVAR*3 for MH) is indexed at 4+iBeg (iBeg=0), and is
> thus indexing out of range.
>
> Where should this be pointing? Should Vm,Vc,Vp point to 1:3 in Data1D?
Hello Mark,
Nice detective work. Yes, this is wrong. The correction should consist of
the following substitutions
s/2\+iBeg/1/
s/3\+iBeg/2/
s/4\+iBeg/3/
as you have suspected. We will apply this fix to our code and for future
releases.
This error seems to have been caused by copying some code from another
file (probably hy_uhd_DataReconstructNormalDir_WENO.F90) without proper
adjustments.
Readers should note that this bug is specific to the "RadFLAH"
(;Radiation-flux-limiter-aware Hydro') variants of Hydro routines, which
reside under unsplit_rad in the source tree. Other configurations, whether
1T or 3T, are NOT affected.
Also, note that hy_uhd_DataReconstructNormalDir_MH is only used when
MUSCL-Hancock reconstruction is applied, i.e., when the runtime parameter
'order' is set to 2.
Klaus
More information about the flash-users
mailing list