<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">Well I see your point about the declaration of dt in Simulation_interface. I will look at implementing my (currently working) solution in the Heat unit. One issue could be that the call of Driver_computeDt calculates various dt's. I believe that it would not set dt below dtmin. Currently I use dtinit as mentioned, which is smaller than dtmin, since the state after the explosion is initiated involves such large gradients. Of course the timestep quickly gets increased, but the single short timestep may be what's necessary to avoid numerical errors.</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">Jon</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 7, 2017 at 1:19 PM, 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 Wed, 7 Jun 2017, Slavin, Jonathan wrote:<br>
<br>
> Hi all,<br>
><br>
> Just thought that I'd let you know that I got my multiple explosion runs<br>
> working. What made all the difference is setting the time step to a very<br>
> small value, I used the initial dt value. So this involved adding<br>
> use Driver_data, ONLY : dr_dtInit<br>
><br>
> and changing the declaration of dt to<br>
> real, intent(inout) :: dt<br>
> (Can one change a value of a variable declared intent(in)?)<br>
<br>
</span>Jon,<br>
<br>
Even if your compiler allowed you to do that (many don't), it would be<br>
wrong to change the value of a variable that is declared intent(in). The<br>
caller of the subroutine could get the modified value returned, or not,<br>
and it may depend on the compiler {,version,optimization level,(...)}<br>
what happens.<br>
<br>
Additionally, IF you made your change<br>
<br>
real, intent(in) :: dt -> real, intent(inout) :: dt<br>
<br>
in (your copy of) Simulation_adjustEvolution.F90 but NOT also in<br>
Simulation_interface.F90, then you have created code that is not valid<br>
Fortran. Again the compiler is free to do what it wants in this case -<br>
return the changed value, keep the old value, trigger a runtime error, ...<br>
I am pointing this out because compilers often do not detect these errors.<br>
<br>
I agree with Tomasz Plewa's response that implementing your heating in the<br>
'Heat' unit would be preferable. Your routine would be called in the right<br>
place by Driver_evolveFlash, AND you would have an 'official' way of<br>
influencing the time step by implementing / modifying Heat_computeDt<br>
(which already gets called from Driver_computeDt).<br>
<br>
I think of Simulation_adjustEvolution as a convenient interface to<br>
implement small adjustments to the solution ('small' in some sense -<br>
updating some additional purely diagnostic variables would count, for<br>
example.) I think it should not be used to 'sneak in' significant physics<br>
operators or source terms.<br>
<span class="HOEnZb"><font color="#888888"><br>
Klaus<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_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: (617) 496-7981 Cambridge, MA 02138-1516<br>cell: (781) 363-0035 USA<br>________________________________________________________<br><br></div></div></div></div>
</div></div>