[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