[FLASH-USERS] Bug in 3T hy_uhd_DataReconstructNormalDir_MH.F90

[Mark Richardson]

Hi Klaus,

  Thanks for that. I'm currently running my code with a lot of debug flags
on to try and figure out why it's crashing, and this is what flagged that
particular typo.

  Currently, I'm getting a weird issue that in the step after a refinement
occurs the value of grid_changed is 0 again in gr_hypreGridStatus, which
means the hypre array gr_hypreLower is improperly allocated by the time I
get to gr_hypreSetIniGuess for some processors, and I crash.

 Looking in Driver_evolveFlash, I see that in the step after a refinement
occurs, grid_changed gets changed from 1 back to 0 in Hydro, but this is
before the source terms are called, so they don't actually know that the
grid has changed.

Is this the expected behaviour of grid_changed? Did it used to happen at
another time so that the source terms would also see it?

Thank you for your help,
  -Mark


On 9 May 2016 at 19:42, Klaus Weide <klaus at flash.uchicago.edu> wrote:

> 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
>



-- 

Mark Richardson
Beecroft Postdoctoral Fellow, Department of Physics
Denys Wilkinson Building - 555F
University of Oxford
Mark.Richardson at physics.ox.ac.uk
+44 1865 280793
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://flash.rochester.edu/pipermail/flash-users/attachments/20160510/bff7862c/attachment.htm>