<div dir="ltr"><div><div dir="ltr"><div>Hi Klaus,</div><div><br></div><div>Thanks for the reply! And hope all is well with you!<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Nov 12, 2020 at 6:13 PM Klaus Weide <<a href="mailto:klaus@flash.uchicago.edu">klaus@flash.uchicago.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, 11 Nov 2020, Alan Calder wrote:<br>
<br>
> First I should note that things work well with the Gnu compilers. We do not<br>
> see this problem when compiling with the gnu compilers.<br>
<br>
That's good.<br>
<br>
Does this also mean that you don't get any "WARNING after gc filling" <br>
messages with GNU compilers, in the situation where you did get them with <br>
the Cray compiler?<br>
<br></blockquote><div>Yep. I ran with all the debugging options of the Gnu compiler and saw nothing unusual. We also compiled and ran with the Nvidia compiler without any issues.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> The shortest possible summary is that the code seems to enter an unphysical<br>
> state and crash, <br>
<br>
I don't have an idea what's going on here. Just want to point you to a <br>
couple of runtime parameters that you may find useful in this kind of <br>
situation:<br>
<br>
   D dr_dtMinContinue  Minimum computed timestep to continue the simulation<br>
   PARAMETER dr_dtMinContinue      REAL    0.0     [0.0 ...]<br>
<br>
   D dr_dtMinBelowAction  Action to take when computed new timestep is below dr_dtMinContinue.<br>
   D & Use 0 for none (abort immediately), 1 for "write checkpoint then abort"<br>
   PARAMETER dr_dtMinBelowAction   INTEGER 1       [0,1]<br>
<br>
<br></blockquote><div><br></div><div>I'll try these.<br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> and with the split hydro solver I see a warning<br>
> <br>
> WARNING after gc filling: min. unk(EINT_VAR)=9.9999999735241242E-11<br>
>   PE=4     block=6<br>
>                     type=1<br>
> <br>
<br>
These indicate that you have very small values of internal energy in <br>
some cells. Not sure now whether that's kind of a normal thing for Sedov<br>
close to the origin...  Maybe lower "smallE" to eliminate the warning?<br>
Since this happens at the very beginning, maybe you can plot the initial<br>
condition to figure out what's going on.<br>
<br>
Not sure why this would not apply equally to "split" and "unsplit" Hydro.<br>
<br>
<br>
> We compile with -c -g -G 2 -s real64 -s integer32 and the code generates a<br>
> few warnings, none of which seem relevant.<br>
<br>
I agree that the compilation warnings don't appear to be of immediate <br>
concern.<br>
<br>
Klaus<br>
</blockquote></div><br clear="all"></div><div>It may well be an issue with the Cray compiler. We were playing with valgrind and a few other things and saw messages that suggested that perhaps there might be something missing for the ARM architecture.</div><div><br></div><div>[acalder@fj-debug1 object]$ mpirun -n 1 valgrind ./flash4<br>==20316== Memcheck, a memory error detector<br>==20316== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.<br>==20316== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info<br>==20316== Command: ./flash4<br>==20316==<br>ARM64 front end: branch_etc<br>disInstr(arm64): unhandled instruction 0xD5380000<br>disInstr(arm64): 1101'0101 0011'1000 0000'0000 0000'0000<br>==20316== valgrind: Unrecognised instruction at address 0x58d09b8.<br>==20316==    at 0x58D09B8: __cray_cpu_detect_arm (in /lustre/software/CPE/cray/pe/cce-sve/10.0.1/cce/aarch64/lib/libu.so.1.0)<br>==20316==    by 0x58D1A9F: memcpy (in /lustre/software/CPE/cray/pe/cce-sve/10.0.1/cce/aarch64/lib/libu.so.1.0)<br>==20316== Your program just tried to execute an instruction that Valgrind<br>==20316== did not recognise.  There are two possible reasons for this.<br>==20316== 1. Your program has a bug and erroneously jumped to a non-code<br>==20316==    location.  If you are running Memcheck and you just saw a<br>==20316==    warning about a bad jump, it's probably your program's fault.<br>==20316== 2. The instruction is legitimate but Valgrind doesn't handle it,<br>==20316==    i.e. it's Valgrind's fault.  If you think this is the case or<br>==20316==    you are not sure, please let us know and we'll try to fix it.<br>==20316== Either way, Valgrind will now raise a SIGILL signal which will<br>==20316== probably kill your program.<br></div><div><br></div><div><br></div><div> I'll keep digging and report anything I find.</div><div><br></div><div>Thanks!</div><div><br></div><div>Alan<br></div><div><div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Alan C. Calder<br>Department of Physics and Astronomy<br>State University of New York at Stony Brook<br>Stony Brook, NY 11794-3800<br><br>office: ESS 438<br>phone:  (631) 632-1176<br>fax:  (631) 632-1745<br>web: <a href="http://www.astro.sunysb.edu/acalder" target="_blank">http://www.astro.sunysb.edu/acalder</a><br></div></div></div></div></div>