[FLASH-USERS] zoom-out simulations

Thu May 30 10:41:01 EDT 2019

I should have just sent you the descriptions below. Hopefully they are not too confusing (I think I wrote them…).

The answer to your question is Yes, the first refinement reduction will occur after `t=gr_lrefineMaxRedTRef+gr_lrefineMaxRedTimeScale`.

Sean

gr_lrefineMaxRedDoByLogR [BOOLEAN] [FALSE]
        Softly force effectively a lower lrefine_max depending on distance from
        center. See gr_lrefineMaxRedRadiusFact.
    gr_lrefineMaxRedDoByTime [BOOLEAN] [FALSE]
        Lower the effective lrefine_max as a function of time. See runtime
        parameters gr_lrefineMaxRedTRef, gr_lrefineMaxRedTimeScale, and
        gr_lrefineMaxRedLogBase.
    gr_lrefineMaxRedLogBase [REAL] [10.0]
        Valid Values: 1.0 to INFTY
        Logarithm base for determining when repeated reductions in effective
        lrefine_max should happen. The nth reduction will happen at
        t=gr_lrefineMaxRedTRef+gr_lrefineMaxRedTimeScale*gr_lrefineMaxRedLogBase**(n-1).
    gr_lrefineMaxRedRadiusFact [REAL] [0.0]
        Valid Values: 0.0 to INFTY
        factor that determines a minimum resolution (and thus maximum refinement
        level) based on distance from a center. See x_refine_center,
        y_refine_center, z_refine_center for the center coordinates.  This is
        approximately (linearly) equivalent to requiring a minimum *angular*
        resolution, within the limits set by the global lrefine_min and
        lrefine_max.  Only used when gr_lrefineMaxRedDoByLogR is TRUE.
    gr_lrefineMaxRedTRef [REAL] [0.0]
        Valid Values: Unconstrained
        reference time for time-based max level reduction. The effective
        reduction of lrefine_max only kicks in for times greater than
        gr_lrefineMaxRedTRef. The first time lrefine_max is effectively lowered
        actually happens at t=gr_lrefineMaxRedTRef+gr_lrefineMaxRedTimeScale.
    gr_lrefineMaxRedTimeScale [REAL] [1.0]
        Valid Values: TINY to INFTY
        the time scale for effectively lowering lrefine_max: The first reduction
        takes place at t=gr_lrefineMaxRedTRef+gr_lrefineMaxRedTimeScale.

----------------------------------------------------------------------
Sean M. Couch, Ph.D.
Assistant Professor
Department of Physics and Astronomy
Department of Computational Mathematics, Science, and Engineering
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 30, 2019, 10:35 AM -0400, Slavin, Jonathan <jslavin at cfa.harvard.edu>, wrote:
Hi Sean,

Yes sounds like what I'm after. I'll have to look into how to use those for my case. If I were to use the time one, would it de-resolve the highly resolved regions after the given time is reached?

Jon

On Thu, May 30, 2019 at 10:28 AM Sean M. Couch <couch at pa.msu.edu<mailto:couch at pa.msu.edu>> wrote:
Hi Jon,

Depending on what exactly you are looking to do, it might already be possible with FLASH. FLASH4 already has the capability to reduce the maximum allowed refinement level as a function of radius. See the runtime parameter `gr_lrefineMaxRedDoByLogR` and `gr_lrefineMaxRedRadiusFact`. The latter is a bit arcane, but essentially sets the “angular” resolution of the resulting grid. But the value chose depends on the number of zones per block (`nxb`) since the resolution limiting is actually based on the _block_ size, not the _zone_ size directly.

The second already-implemented feature that could be of use here is the runtime param `gr_lrefineMaxRedDoByTime`. This, if True, decreases the maximum allowed refinement level anywhere on the grid as a function of time. The behavior is set by the params `gr_lrefineMaxRedLogBase`, `gr_lrefineMaxRedTRef`, and `gr_lrefineMaxRedTimeScale`. See appropriate documentation online or the code directly. Combined with `gr_lrefineMaxRedDoByLogR`, this means you can “de-resolve” the inner region of your grid as the feature you are interested in moves out in radius. This nets you not only a reduction in the total number of zones in the simulation but, usually, a nice increase in the time step size. We have been using these features, in various combinations, for years in our supernova simulations.

This all assumes that you are included the “large” scale region from the very start of your simulation. If you want to map an already-run simulation into a larger domain, literally zooming out, that’s harder. I did it a long time ago (with FLASH v2!) when I was a grad student but that code and capability are now part of the geological record, I fear.

Sean

----------------------------------------------------------------------
Sean M. Couch, Ph.D.
Assistant Professor
Department of Physics and Astronomy
Department of Computational Mathematics, Science, and Engineering
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<mailto:couch at pa.msu.edu> --- www.pa.msu.edu/~couch<http://www.pa.msu.edu/~couch>
On May 29, 2019, 1:45 PM -0400, Slavin, Jonathan <jslavin at cfa.harvard.edu<mailto:jslavin at cfa.harvard.edu>>, wrote:
Hi all,

Often simulators will use zoom-in simulations - taking a part of a large simulation to focus on a small region of interest. I would like to do the opposite. I would like to take a fairly small scale simulation and embed it in a larger smooth background and reduce the refinement by a level or two. I imagine that this will require some significant coding, but I was wondering if anyone had tried something like this or could offer suggestions on how to do it. Thanks in advance for any help.

Regards,
Jon

--

Jonathan D. Slavin
Astrophysicist - High Energy Astrophysics Division
Center for Astrophysics | Harvard & Smithsonian
Office: (617) 496-7981 | Cell: (781) 363-0035
60 Garden Street | MS 83 | Cambridge, MA 02138

--

Jonathan D. Slavin
Astrophysicist - High Energy Astrophysics Division
Center for Astrophysics | Harvard & Smithsonian
Office: (617) 496-7981 | Cell: (781) 363-0035
60 Garden Street | MS 83 | Cambridge, MA 02138

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://flash.rochester.edu/pipermail/flash-users/attachments/20190530/e121cfa5/attachment.htm>