[FLASH-USERS] ensuring div B = 0 when adjusting evolution

[Slavin, Jonathan]

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.

Jon

On Wed, Jun 7, 2017 at 1:19 PM, Klaus Weide <klaus at flash.uchicago.edu>
wrote:

> On Wed, 7 Jun 2017, Slavin, Jonathan wrote:
>
> > Hi all,
> >
> > 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
> > use Driver_data, ONLY : dr_dtInit
> >
> > and changing the declaration of dt to
> > real, intent(inout) :: dt
> > (Can one change a value of a variable declared intent(in)?)
>
> Jon,
>
> Even if your compiler allowed you to do that (many don't), it would be
> wrong to change the value of a variable that is declared intent(in). The
> caller of the subroutine could get the modified value returned, or not,
> and it may depend on the compiler {,version,optimization level,(...)}
> what happens.
>
> Additionally, IF you made your change
>
>    real, intent(in) :: dt   ->   real, intent(inout) :: dt
>
> in (your copy of) Simulation_adjustEvolution.F90 but NOT also in
> Simulation_interface.F90, then you have created code that is not valid
> Fortran. Again the compiler is free to do what it wants in this case -
> return the changed value, keep the old value, trigger a runtime error, ...
> I am pointing this out because compilers often do not detect these errors.
>
> I agree with Tomasz Plewa's response that implementing your heating in the
> 'Heat' unit would be preferable. Your routine would be called in the right
> place by Driver_evolveFlash, AND you would have an 'official' way of
> influencing the time step by implementing / modifying Heat_computeDt
> (which already gets called from Driver_computeDt).
>
> I think of Simulation_adjustEvolution as a convenient interface to
> implement small adjustments to the solution ('small' in some sense -
> updating some additional purely diagnostic variables would count, for
> example.) I think it should not be used to 'sneak in' significant physics
> operators or source terms.
>
> Klaus
>



-- 
________________________________________________________
Jonathan D. Slavin                 Harvard-Smithsonian CfA
jslavin at cfa.harvard.edu       60 Garden Street, MS 83
phone: (617) 496-7981       Cambridge, MA 02138-1516
cell: (781) 363-0035             USA
________________________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://flash.rochester.edu/pipermail/flash-users/attachments/20170607/0abb7001/attachment.htm>