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

Fri May 26 17:08:41 EDT 2017

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. 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

         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)

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.

Hope that helps,

Josh Wall

On Fri, May 26, 2017, 4:39 PM Slavin, Jonathan <jslavin at cfa.harvard.edu>
wrote:

> To answer Sean and Ernesto's questions:
> I am using the USM solver and AMR.  I have now determined that div B is
> still 0 after the second explosion, which is not too surprising since, for
> this run, I have not changed the magnetic field and include div B cleaning
> (killdivb = .true.). So the problem is not with non-zero div B but with the
> large B fluctuations that are initiated. I noticed that there are small
> scale fluctuations in the region where the second explosion is initiated
> before the explosion, though the field is weak ~ 0.01 muG.  The
> fluctuations after the explosion go from ~ -1000 muG - +1000 muG.  I do
> expect amplification of B field fluctuations at the shock, but not to that
> extent.
>
> The way I'm initiating the second explosion is (almost) the same way I
> initiate the first one - I set the pressure of parcels within a given
> radius to a value such that the sum of the energy in those parcels is equal
> to the value I want for the explosion (1.E51 ergs).  I set the density to a
> value so as to have the mass total to 8 solar masses.  So all the energy is
> thermal at first.  I'll see about calling the EOS unit, since I haven't
> done that.  Any additional info on how to do that would be appreciated.
>
> Thanks,
> Jon
>
> On Fri, May 26, 2017 at 1:00 PM, <flash-users-request at flash.uchicago.edu>
> wrote:
>>
>> ---------- Forwarded message ----------
>> From: ERNESTO ZURBRIGGEN <ezurbriggen at unc.edu.ar>
>> To: flash-users at flash.uchicago.edu
>> Cc:
>> Bcc:
>> Date: Fri, 26 May 2017 10:56:45 -0300
>> Subject: Re: [FLASH-USERS] ensuring div B = 0 when adjusting evolution
>> Hi Jon!
>>
>> Have you tried to set off a less intense second supernova explosion? Have
>> you observed the same problems in that case? The second explotion might be
>> much too intense.
>>
>> On the other hand, how do you set the later explotion? I mean, applying
>> the explotion, are you consistently modifying the thermodynamical
>> variables? For example, if you instantaneously modify the density and the
>> temperature, then you also should call the Eos unit to keep the
>> consistence. I have experimented situations in which just modifying
>> velocities and keeping the thermodynamics unaltered, I also had to call the
>> Eos unit in order to maintain consistence
>>
>> Some runtime parameter that might help being on are 'shockDetect' and
>> 'shockLowerCFL' (this last one I think is just in realease 4.4).
>>
>>
>> Best!
>>
> --
>> *Ernesto Zurbriggen*
>>
>> *Instituto de Astronomía Teórica y Experimental (IATE). *
>> *Observatorio Astronómico de Córdoba (OAC), **Universidad Nacional de
>> Córdoba **(UNC)**. *
>> *Teléfono: +54 0351 4331064-5, interno 222. *
>> *Córdoba, Argentina.*
>>
>
>>
>> ---------- Forwarded message ----------
>> From: "Sean M. Couch" <couch at pa.msu.edu>
>> To: "Slavin, Jonathan" <jslavin at cfa.harvard.edu>, flash-users <
>> flash-users at flash.uchicago.edu>
>> Cc:
>> Bcc:
>> Date: Fri, 26 May 2017 14:07:22 +0000
>> Subject: Re: [FLASH-USERS] ensuring div B = 0 when adjusting evolution
>> Hi Jon,
>>
>> Can you give a little more info? Are you using the USM solver? Are you
>> using AMR? Have you actually checked that divB>0 in the output data? A log
>> file from a representative run would be useful.
>>
>> In my experience, the USM solver in cylindrical R-Z coordinates with AMR
>> can be….touchy. But it should work and maintain divB=0! (See, e.g.,
>> http://adsabs.harvard.edu/cgi-bin/nph-data_query?bibcode=2013ApJ...773..136J&link_type=EJOURNAL
>> ).
>>
>> Cheers,
>> Sean
>>
>>
>>
>> ----------------------------------------------------------------------------------------------------------
>> Sean M. Couch
>> Assistant Professor
>> Department of Physics and Astronomy
>> Department of Computational Mathematics, Science, and Engineering
>> National Superconducting Cyclotron Laboratory/Facility for Rare Isotope
>> Beams
>> Michigan State University
>> 567 Wilson Rd, 3250 BPS
>> East Lansing, MI  48824
>> (517) 884-5035    ——    couch at pa.msu.edu    ——    www.pa.msu.edu/~couch
>>
>>
>>
>>
>> On May 25, 2017 at 4:41:45 PM, Slavin, Jonathan (jslavin at cfa.harvard.edu)
>> wrote:
>>
>> Hi all,
>>
>> I'm running MHD simulations where I set off a second supernova explosion
>> within a pre-existing remnant.  I'm using Simulation_adjustEvolution for
>> this.  However, I'm running into a problem with the magnetic field just
>> after initiating the second explosion.  I'm getting very large
>> pixel-to-pixel variations in Bx and By at the edge of the new expanding
>> blast wave.  I'm thinking that it could be because of non-zero div B in the
>> region in which the explosion is generated. So my question is, does anyone
>> have a suggestion for div B cleaning at the point that the explosion is
>> started, i.e. within Simulation_adjustEvolution, to prevent the problems
>> I'm having? I don't really expect the B field to be dynamically important
>> inside the remnant (beta >> 1), so accuracy of the B field is probably not
>> important there.  I should add that I'm doing these calculations in 2D
>> cylindrical symmetry (R-Z).  Thanks in advance for any help.
>>
>> Regards,
>> Jon
>>
>>
>> _______________________________________________
>> flash-users mailing list
>> flash-users at flash.uchicago.edu
>> http://flash.uchicago.edu/mailman/listinfo/flash-users
>>
> --
> ________________________________________________________
> 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/20170526/b55498bc/attachment-0001.htm>