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

[Slavin, Jonathan]

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)?)
and then when the explosion is initiated setting dt = dr_dtInit
So all the issues of large B fluctuations was due to the overly large time
step at the moment the explosion is initiated.

Jon


On Mon, Jun 5, 2017 at 4:22 AM, Joshua Wall <joshua.e.wall at gmail.com> wrote:

> Hello Jon and Klaus,
>
>      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.
>
>      I see in the call for Grid_fillGuardCells.F90 right at the top:
>
>   !We can skip this guard cell fill if the guard cells are up to date.
>   if (gridDataStruct /= WORK) then
>      skipThisGcellFill = gr_gcellsUpToDate
>   else
>      skipThisGcellFill = .false.
>   end if
>
> This looks to me like if I haven't called:
>
> call Grid_notifySolnDataUpdate( (/ EINT_VAR, DENS_VAR, ENER_VAR /) )
>
> 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?
>
> If so, this may also be Jon's error.
>
> Cordially,
>
> Josh
>
>
>
> On Wed, May 31, 2017 at 12:01 AM Klaus Weide <klaus at flash.uchicago.edu>
> wrote:
>
>> On Fri, 26 May 2017, Joshua Wall wrote:
>>
>> > Hello Jon,
>> >
>> >      There's two ways to do the EOS update. One is to call Eos_wrapped
>> at
>> > the end of the block loop on each block you update as you go through the
>> > loop. Make sure you pass which mode you want based on the variables you
>> > updated, which here sounds like pressure and internal energy.
>>
>> That's usually the way to do it.
>>
>> > So that would
>> > look something like:
>> >
>> >
>> > do blk=1, numBlocks
>> >
>> > blockID = blockList(blk)
>> >
>> > call Grid_getBlkLimits(blockID, blkLimits, blkLimitsGC)
>> >
>> > call Grid_getBlkPtr(blockID, solnData)
>> >    do i
>> >      do j
>> >        do k
>> >
>> >           solnData(DENS_VAR,i,j,k) = stuff
>> >           solnData(EINT_VAR,i,j,k) = stuff
>>
>> To make sure the Eos_wrapped call below does not get confused,
>> one should also modify ENER_VAR when modifying EINT_VAR.
>> Usually by adding the same amount to both variables.
>> (Even more variables should be modified if using 3T Hydro
>> and Eos.)
>>
>> >
>> >          end do
>> >       end do
>> >     end do
>> >
>> >     call Eos_wrapped(MODE_DENS_EI, blkLimits, blockID)
>> >
>> > end do
>> >
>> > The other way to do it is to:
>> >
>> >  call Grid_fillGuardCells(CENTER, ALL_DIR, LEAF, doEos=.true.,
>> > eosMode=MODE_DENS_EI)
>>
>> 1. This call is not valid as written, or at least extremely confusing.
>> I assume the "LEAF" is meant as a value for the (optional)
>> "selectBlockType" dummy argument; if that is true, the call should be
>> written as
>>
>> |  call Grid_fillGuardCells(CENTER, ALL_DIR, selectBlockType=LEAF,
>> |   doEos=.true.,eosMode=MODE_DENS_EI)
>>
>> Otherwise the compiler will interpret it as ...,minLayers=LEAF,...,
>> which is probably not intended.
>>
>> 1. This call does *not* apply the Eos to interior cells, but only to
>> (some) guard cells. In some previous version of FLASH, the doEos may have
>> applied to all cells (interior+guard), but that has not been the case
>> for several releases. Now the Eos is only applied to guard cells that
>> correspond to neighboring blocks at a different refinement.
>>
>> > This method ensures that whatever happens next, not only is the EOS
>> updated
>> > all values for each cell, *but also those values are valid in guard
>> cells
>> > on other processors*. I mention this method because using the
>> Eos_wrapped
>> > and forgetting to fill guard cells after has been a "gotcha" moment for
>> me
>> > in the past, and was a very tricky error to track down. But guard cell
>> > filling is also expensive, so if you know its safe to not do it,
>> > Eos_wrapped is the way to go.
>>
>> The general rule should be:
>>
>>  * call Eos_wrapped at the end of your code, if you have modified any
>>    variables that could make the thermodynamic state inconsistent;
>>  * call Grid_fillGuardCells at the beginning of your code if you need
>>    to refer to any variables in guard cells - with or without doEos
>>    depending on the needs of your code.
>>
>> unless you *really* understand the consequences of deviating from this
>> convention.
>>
>> Klaus
>>
> --
> Joshua Wall
> Doctoral Candidate
> Department of Physics
> Drexel University
> 3141 Chestnut Street
> Philadelphia, PA 19104
>



-- 
________________________________________________________
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/186d975b/attachment.htm>