[FLASH-USERS] ensuring div B = 0 when adjusting evolution
Joshua Wall
joshua.e.wall at gmail.com
Wed Jun 7 11:03:10 EDT 2017
Hello all,
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).
So I guess I'm advocating this should likely be the default ordering
in Flash.
Cordially,
Josh
On Wed, Jun 7, 2017 at 4:55 PM Sean M. Couch <couch at pa.msu.edu> wrote:
> 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)
> 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>
> 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
> ________________________________________________________
>
> --
Joshua Wall
Doctoral Candidate
Department of Physics
Drexel University
3141 Chestnut Street
Philadelphia, PA 19104
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://flash.rochester.edu/pipermail/flash-users/attachments/20170607/c155b5f5/attachment.htm>
More information about the flash-users
mailing list