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

[Sean M. Couch]

Hi Jon,

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.

Cheers,
Sean


On June 7, 2017 at 9:37:19 AM, Slavin, Jonathan (jslavin at cfa.harvard.edu<mailto:jslavin at cfa.harvard.edu>) 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)?)
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<mailto: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<mailto: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<mailto: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/e4a155f6/attachment-0001.htm>