<div dir="ltr">Hi Klaus,<div><br></div><div> 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.</div><div><br></div><div> 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. </div><div><br></div><div> 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. </div><div><br></div><div>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?</div><div> </div><div>Thank you for your help,</div><div> -Mark</div><div> </div></div><div class="gmail_extra"><br><div class="gmail_quote">On 9 May 2016 at 19:42, Klaus Weide <span dir="ltr"><<a href="mailto:klaus@flash.uchicago.edu" target="_blank">klaus@flash.uchicago.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mon, 9 May 2016, Mark Richardson wrote:<br>
<br>
> Hello,<br>
><br>
> there appears to be a bug in hy_uhd_DataReconstructNormalDir_MH.F90, at<br>
> least for the 3T case.<br>
><br>
> For the MUSCL-Hancock case, korder is set to 1 in<br>
> hy_uhd_dataReconstOneStep.F90, but in<br>
> hy_uhd_DataReconstructNormalDir_MH.F90 at line 227 Data1D (which points to<br>
> U(:,ix-korder:ix+korder,iy,iz) for the x sweep say, thus sizeof(Data1D) =<br>
> NVAR * (2korder+1) = NVAR*3 for MH) is indexed at 4+iBeg (iBeg=0), and is<br>
> thus indexing out of range.<br>
><br>
> Where should this be pointing? Should Vm,Vc,Vp point to 1:3 in Data1D?<br>
<br>
</span>Hello Mark,<br>
<br>
Nice detective work. Yes, this is wrong. The correction should consist of<br>
the following substitutions<br>
<br>
s/2\+iBeg/1/<br>
s/3\+iBeg/2/<br>
s/4\+iBeg/3/<br>
<br>
as you have suspected. We will apply this fix to our code and for future<br>
releases.<br>
<br>
This error seems to have been caused by copying some code from another<br>
file (probably hy_uhd_DataReconstructNormalDir_WENO.F90) without proper<br>
adjustments.<br>
<br>
Readers should note that this bug is specific to the "RadFLAH"<br>
(;Radiation-flux-limiter-aware Hydro') variants of Hydro routines, which<br>
reside under unsplit_rad in the source tree. Other configurations, whether<br>
1T or 3T, are NOT affected.<br>
<br>
Also, note that hy_uhd_DataReconstructNormalDir_MH is only used when<br>
MUSCL-Hancock reconstruction is applied, i.e., when the runtime parameter<br>
'order' is set to 2.<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
Klaus<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><br>Mark Richardson<br><div>Beecroft Postdoctoral Fellow, Department of Physics<div>Denys Wilkinson Building - 555F</div><div>University of Oxford<div><a href="mailto:Mark.Richardson@physics.ox.ac.uk" target="_blank">Mark.Richardson@physics.ox.ac.uk</a><br><div>+44 1865 280793</div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div>
</div>