<div dir="ltr">Hello all,<div><br></div><div> Actually, I don't normally use the USM solver (though I'm trying it recently thanks to Sean!) so I hadn't looked at the Driver_evolveFlash for it. But I now noticed that it looks like it calculates the timestep for everything *before* Simulation_adjustEvolution is called. I think if the line for Simulation_adjustEvolution is moved ahead of the timestep calculation (where presumably the sound speed / velocity / pressure of the gas is changed) then the timestep calculation will pick it up and set the correct timestep for Hydro to take (which is likely larger than dtinit but smaller than before the SN explosion).</div><div><br></div><div> So I guess I'm advocating this should likely be the default ordering in Flash.</div><div><br></div><div>Cordially,</div><div><br></div><div>Josh</div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Jun 7, 2017 at 4:55 PM Sean M. Couch <<a href="mailto:couch@pa.msu.edu">couch@pa.msu.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">
<div id="m_4322912710388861993bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">
Hi Jon,</div>
<div id="m_4322912710388861993bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">
<br>
</div>
<div id="m_4322912710388861993bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">
I think you could have also simply set the runtime parameter `dtmax` equal to `dtinit`, or some other small value, to achieve this in a simpler way without editing the code.</div>
<br>
<div id="m_4322912710388861993bloop_sign_1496847266096630016" class="m_4322912710388861993bloop_sign">Cheers,
<div>Sean</div>
</div></div><div style="word-wrap:break-word">
<br>
<p class="m_4322912710388861993airmail_on">On June 7, 2017 at 9:37:19 AM, Slavin, Jonathan (<a href="mailto:jslavin@cfa.harvard.edu" target="_blank">jslavin@cfa.harvard.edu</a>) wrote:</p>
<blockquote type="cite" class="m_4322912710388861993clean_bq"><span>
<div>
<div></div>
<div>
<div dir="ltr">
<div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">
Hi all,</div>
<div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">
<br>
</div>
<div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">
Just thought that I'd let you know that I got my multiple explosion runs working. What made all the difference is setting the time step to a very small value, I used the initial dt value. So this involved adding</div>
<div class="gmail_default"><font face="arial, helvetica, sans-serif">use Driver_data, ONLY : dr_dtInit</font><br>
</div>
<div class="gmail_default"><font face="arial, helvetica, sans-serif"><br>
</font></div>
<div class="gmail_default"><font face="arial, helvetica, sans-serif">and changing the declaration of dt to</font></div>
<div class="gmail_default"><font face="arial, helvetica, sans-serif">real, intent(inout) :: dt<br>
</font></div>
<div class="gmail_default"><font face="arial, helvetica, sans-serif">(Can one change a value of a variable declared intent(in)?)</font></div>
<div class="gmail_default"><font face="arial, helvetica, sans-serif">and then when the explosion is initiated setting dt = dr_dtInit</font></div>
<div class="gmail_default"><font face="arial, helvetica, sans-serif">So all the issues of large B fluctuations was due to the overly large time step at the moment the explosion is initiated.</font></div>
<div class="gmail_default"><font face="arial, helvetica, sans-serif"><br>
</font></div>
<div class="gmail_default"><font face="arial, helvetica, sans-serif">Jon</font></div>
<div class="gmail_default"><font face="arial, helvetica, sans-serif"><br>
</font></div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Mon, Jun 5, 2017 at 4:22 AM, Joshua Wall <span dir="ltr">
<<a href="mailto:joshua.e.wall@gmail.com" target="_blank">joshua.e.wall@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">Hello Jon and Klaus,
<div><br>
</div>
<div> I have been thinking about guard cell filling in Jon's problem (and I'm also tracking down a bug at the moment I think is related to gc filling) and perhaps have hit on something. So I wanted to check with Klaus and see if this is correct.</div>
<div><br>
</div>
<div> I see in the call for Grid_fillGuardCells.F90 right at the top:</div>
<div><br>
</div>
<div>
<div><font face="monospace"> !We can skip this guard cell fill if the guard cells are up to date.</font></div>
<div><font face="monospace"> if (gridDataStruct /= WORK) then</font></div>
<div><font face="monospace"> skipThisGcellFill = gr_gcellsUpToDate</font></div>
<div><font face="monospace"> else</font></div>
<div><font face="monospace"> skipThisGcellFill = .false.</font></div>
<div><font face="monospace"> end if</font></div>
<div><br>
</div>
<div>This looks to me like if I haven't called:</div>
<div><br>
</div>
<div><font face="monospace">call Grid_notifySolnDataUpdate( (/ EINT_VAR, DENS_VAR, ENER_VAR /) )</font><br>
</div>
<div><br>
</div>
That silently the guard cell filling call will be ignored if they were filled just before my routine modified variables without notifying the Grid unit. Is that correct Klaus?</div>
<div><br>
</div>
<div>If so, this may also be Jon's error.</div>
<div><br>
</div>
<div>Cordially,</div>
<div><br>
</div>
<div>Josh</div>
<div>
<div class="m_4322912710388861993h5">
<div><br>
</div>
<div><br>
</div>
<div><br>
<div class="gmail_quote">
<div dir="ltr">On Wed, May 31, 2017 at 12:01 AM Klaus Weide <<a href="mailto:klaus@flash.uchicago.edu" target="_blank">klaus@flash.uchicago.edu</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Fri, 26 May 2017, Joshua Wall wrote:<br>
<br>
> Hello Jon,<br>
><br>
> There's two ways to do the EOS update. One is to call Eos_wrapped at<br>
> the end of the block loop on each block you update as you go through the<br>
> loop. Make sure you pass which mode you want based on the variables you<br>
> updated, which here sounds like pressure and internal energy.<br>
<br>
That's usually the way to do it.<br>
<br>
> So that would<br>
> look something like:<br>
><br>
><br>
> do blk=1, numBlocks<br>
><br>
> blockID = blockList(blk)<br>
><br>
> call Grid_getBlkLimits(blockID, blkLimits, blkLimitsGC)<br>
><br>
> call Grid_getBlkPtr(blockID, solnData)<br>
> do i<br>
> do j<br>
> do k<br>
><br>
> solnData(DENS_VAR,i,j,k) = stuff<br>
> solnData(EINT_VAR,i,j,k) = stuff<br>
<br>
To make sure the Eos_wrapped call below does not get confused,<br>
one should also modify ENER_VAR when modifying EINT_VAR.<br>
Usually by adding the same amount to both variables.<br>
(Even more variables should be modified if using 3T Hydro<br>
and Eos.)<br>
<br>
><br>
> end do<br>
> end do<br>
> end do<br>
><br>
> call Eos_wrapped(MODE_DENS_EI, blkLimits, blockID)<br>
><br>
> end do<br>
><br>
> The other way to do it is to:<br>
><br>
> call Grid_fillGuardCells(CENTER, ALL_DIR, LEAF, doEos=.true.,<br>
> eosMode=MODE_DENS_EI)<br>
<br>
1. This call is not valid as written, or at least extremely confusing.<br>
I assume the "LEAF" is meant as a value for the (optional)<br>
"selectBlockType" dummy argument; if that is true, the call should be<br>
written as<br>
<br>
| call Grid_fillGuardCells(CENTER, ALL_DIR, selectBlockType=LEAF,<br>
| doEos=.true.,eosMode=MODE_DENS_EI)<br>
<br>
Otherwise the compiler will interpret it as ...,minLayers=LEAF,...,<br>
which is probably not intended.<br>
<br>
1. This call does *not* apply the Eos to interior cells, but only to<br>
(some) guard cells. In some previous version of FLASH, the doEos may have<br>
applied to all cells (interior+guard), but that has not been the case<br>
for several releases. Now the Eos is only applied to guard cells that<br>
correspond to neighboring blocks at a different refinement.<br>
<br>
> This method ensures that whatever happens next, not only is the EOS updated<br>
> all values for each cell, *but also those values are valid in guard cells<br>
> on other processors*. I mention this method because using the Eos_wrapped<br>
> and forgetting to fill guard cells after has been a "gotcha" moment for me<br>
> in the past, and was a very tricky error to track down. But guard cell<br>
> filling is also expensive, so if you know its safe to not do it,<br>
> Eos_wrapped is the way to go.<br>
<br>
The general rule should be:<br>
<br>
* call Eos_wrapped at the end of your code, if you have modified any<br>
variables that could make the thermodynamic state inconsistent;<br>
* call Grid_fillGuardCells at the beginning of your code if you need<br>
to refer to any variables in guard cells - with or without doEos<br>
depending on the needs of your code.<br>
<br>
unless you *really* understand the consequences of deviating from this<br>
convention.<br>
<br>
Klaus<br>
</blockquote>
</div>
</div>
</div>
</div>
</div>
<div class="m_4322912710388861993HOEnZb">
<div class="m_4322912710388861993h5">
<div dir="ltr">--<br>
</div>
<div data-smartmail="gmail_signature">
<div dir="ltr">
<div>
<div>
<div>
<div>
<div>Joshua Wall<br>
</div>
Doctoral Candidate<br>
</div>
Department of Physics<br>
</div>
Drexel University<br>
</div>
3141 Chestnut Street<br>
</div>
Philadelphia, PA 19104<br>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
--<br>
<div class="m_4322912710388861993gmail_signature" data-smartmail="gmail_signature">
<div dir="ltr">
<div>
<div dir="ltr">________________________________________________________<br>
Jonathan D. Slavin Harvard-Smithsonian CfA<br>
<a href="mailto:jslavin@cfa.harvard.edu" target="_blank">jslavin@cfa.harvard.edu</a> 60 Garden Street, MS 83<br>
phone: <a href="tel:(617)%20496-7981" value="+16174967981" target="_blank">(617) 496-7981</a> Cambridge, MA 02138-1516<br>
cell: <a href="tel:(781)%20363-0035" value="+17813630035" target="_blank">(781) 363-0035</a> USA<br>
________________________________________________________<br>
<br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</span></blockquote>
</div></blockquote></div><div dir="ltr">-- <br></div><div data-smartmail="gmail_signature"><div dir="ltr"><div><div><div><div><div>Joshua Wall<br></div>Doctoral Candidate<br></div>Department of Physics<br></div>Drexel University<br></div>3141 Chestnut Street<br></div>Philadelphia, PA 19104<br></div></div>