Changes between Version 1 and Version 2 of AstroBearAmr


Ignore:
Timestamp:
05/18/11 12:43:44 (14 years ago)
Author:
Brandon Shroyer
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • AstroBearAmr

    v1 v2  
    1 At first glance the AMR routine in [ScramblerDoc:../amr__control_8f90.html amr_control.f90] is a little intimidating.  But it can be built up in steps.
    2 
    3 
    4  = Basic Algorithm =
    5 First we'll start with the simplest form of the algorithm containing most of the essential parts.
     1[[PageOutline]]
     2
     3= AMR Explained =
     4At first glance the AMR routine in [ScramblerDoc:../amr__control_8f90.html amr_control.f90] is a little intimidating, but it can be understood by examining the most basic features first.
     5
     6Please note that this is an explanation of AstroBEAR's AMR implementation, not adaptive mesh refinement itself.  Readers who are unfamiliar with AMR might wish to look over some the AMR resources we have on the [CodeExplanation#HowAMRWorks How AstroBEAR Works] page.
     7
     8[[BR]]
     9== Basic Algorithm ==
     10First we'll start with a simplified version of the AMR algorithm.  This version focuses only on the most essential features:
    611
    712{{{
     
    3742   CALL CoarsenDataForParents(n)
    3843END SUBROUTINE AMR
    39 
    40 
    41 }}}
    42 
    43 You'll notice that the AMR routine is recursive - and that it calls itself on the next higher level '''AMR(n+1)''' during each step.  This is because for each step on level n, their are two steps on level n+1.  You'll also notice that every routine is called with a single parameter 'n' specifying the level to operate on.
    44 
    45 * !InitInfos - Since the node structures are already created by the previous level of AMR, the first thing that needs to be done is to allocate data structures associated with the nodes on level n.
    46 * !ProlongateParentsData - After allocating the data structures - they need to be filled with prolongated data from their parent node's data structures
     44}}}
     45
     46In this example, the parameter ''{{{n}}}'' represents the current level of the operation.
     47
     48Remember as we step through the {{{AMR()}}} subroutine that it is ''recursive''.  At each step on level ''{{{n}}}'', {{{AMR(n)}}} within the {{{DO nSteps}}} loop).  calls itself on the next level up (see the calls to {{{AMR(n+1)}}} during each step on level ''{{{n}}}''.  This is because for each step on level {{{n >= 0}}}, there are two steps on level {{{n+1}}}, and the levels above the base level are regridded at each step.
     49
     50'''''IMPORTANT''''':  Because {{{AMR()}}} is recursive, each call to {{{AMR()}}} at level {{{n}}} assumes that certain steps were carried out by the call at level {{{-1}}}.  This can make the structure of {{{AMR()}}} a little confusing, especially once parallelization is included.
     51
     52{{{AMR(n)}}} calls two subroutines before stepping through the simulation to finish initializing level {{{n}}}'s data:
     53 * '''{{{InitInfos(n)}}}''' -- Allocates grid data ({{{InfoDef}}}) structures for the grids on level {{{n}}}.  Note that the tree structure and grid dimensions were created on the previous level {{{n-1}}}; {{{InitInfos()}}} just creates the data structures they reference.
     54
     55 * '''{{{ProlongateParentsData(n)}}}''' -- Populates the level {{{n}}} data structures with prolongated data from their parents on level {{{n-1}}}.
     56
     57
     58Once the data has been constructed, we can begin the work of advancing the simulation.  Each level {{{n}}} will take two steps for every single step taken by {{{n-1}}}, but the process is slightly different on each step for levels above the base level.
    4759* Step 1
    48  * !ApplyOverlaps - After initializing their data structures with prolongated data, grids need to copy data from the previous generation of grids on level n
    49  * ApplyPhysicalBCs - Apply physical boundary conditions.
    50  * !SetErrFlags - Determine which regions to refine
    51  * !BackupNodes - Since we are about to create a new set of child nodes, we need to backup the previous nodes on the child level (n+1)
    52  * !CreateChildrens - Create child nodes on level n+1
    53  * !InheritOldNodeOverlapsChildren - Nested grids mean that spatial relationships (overlaps/neighbors) are inherited from parent grids.  On the first step the previous generation of level n+1 grids are the children of the previous generation of level n grids.
    54  * !InheritNewNodeOverlapsChildren - This inherits the relationships going the other way.  The children of previous level n grids will need to send their data to the children of new level n grids.
     60 * '''{{{ApplyOverlaps(n)}}}''' -- After initializing level {{{n}}} with prolongated data from level {{{n-1}}}, {{{AMR()}}} copies over data from the previous generation of grids on level {{{n}}}.  This higher-resolution data is preferable to data prolongated from the previous level, so {{{AMR()}}} uses it wherever it is available.
     61 * '''{{{ApplyPhysicalBCs(n)}}}''' -- Apply physical boundary conditions to level {{{n}}}.
     62 * '''{{{SetErrFlags(n)}}}''' -- Determine which regions to refine.  Refinement regions are determined by the physical processes involved, as well as specific conditions imposed by the problem modules.
     63 * '''{{{BackupNodes(n+1)}}}''' -- Caches the nodes on the child level (n+1).  We are about to create the new level {{{n+1}}} nodes, and the data referenced by the backed-up nodes will be used when {{{ApplyOverlaps(n+1)}}} is called (see above).
     64 * '''{{{CreateChildrens(n)}}}'''-- A favorite of hillbillies everywhere, this routine creates child nodes on level {{{n+1}}} using the refinement flags set on level {{{n}}}.
     65 * '''{{{InheritOldNodeOverlapsChildren(n)}}}''' -- Nested grids mean that spatial relationships (overlaps and neighbors) are inherited from parent grids.  This routine passes information about the previous generation of {{{n+1}}} grids to the new grids created by {{{CreateChildrens(n)}}}.  This routine is ''only'' executed on step 1 of the {{{AMR()}}} execution loop.
     66 * '''{{{InheritNewNodeOverlapsChildren(n)}}}''' - This inherits the relationships going the other way.  The children of previous level n grids will need to send their data to the children of new level n grids.
    5567 * !InheritNeighborsChildren - Neighbors of children will be children of neighbors
    5668 * !AdvanceGrids - Performs hyperbolic advance of data structures