wiki:BearDataExplained

Version 48 (modified by trac, 12 years ago) ( diff )

The bear.data file


The most important of AstroBEAR's data files, bear.data controls the boundaries of the system and the computational methods used to evolve it. The file is split into two sections: the upper section, which contains globally-applied constants, and the lower section, which contains constants that apply to the root-level grid. This structure is a holdover from BearCLAW, which allowed for different options to be set for each root grid. We generally start with one domain at the root and then decompose it, so we almost never have to add additional root sections to the file.

A detailed explanation of the bear.data elements can be found below. Elements listed in bold italics are "active fields" that you may need to change when you create a new project; while regular italics indicate legacy fields from BearCLAW that are rarely (if ever) changed. It is recommended that the legacy fields be left alone if you are uncertain what the effect will be on your simulation.


Globals

  • Restart: Set to T if the simulation is to be restarted from an existing frame, and F if it is to start from scratch.
  • RestartFromBOV: Set to T if the simulation is to be restarted from a fixed grid brick of values (BOV), and F otherwise.
  • RestartRevision: The code SVN revision which you are restarting from. Code revisions which change the size of the Info structure need this to be set in order to correctly read in the Info*.bin files.
  • MaxLevel Indicates the maximum level of AMR refinement to use. MaxLevel = 2 and MaxLevel = 3 are good starting points if you're not sure how much refinement you'll need.
  • coarsening ratios: The coarsening ratios used by each level of refinement. There should be at least MaxLevel elements in this array; any elements beyond MaxLevel are ignored.
  • run log options: It is recommended that you not tamper with these unless the number of elements in this array is less than MaxLevel, at which point you should just add as many 000 elements as necessary.
  • MinimumGridPoints: Only the first nDim of these values matter; they indicate the minimum number of points in a given dimension that the grids should have. *Side note* Something extra special about our code: There must be at least MaxLevel-1 of these values for the simulation to run.
  • MaxCFLRetry Maximum number of times to reduce dt such that CFL <= cflv(1) before giving up.
  • Output style As of version r439: Set = 0 for Chombo HDF5 output, or = 1 for BOV (brick of values) output.
  • nout: The number of frames that the simulation should produce. This should be an integer greater than 0.
  • TimeStepMethod: Set this parameter to 0 if you want the timestep to be fixed, and to 1 if you want it to be variable. As of r433, for new AMR, set = 2 for fixed timestep and = 3 for variable timestep
  • t0: The initial time. We always set it to 0.
  • tfinal: The final time ( = # years / RunTimeSc(in yrs) )
  • LevelEqSets: Set to T if different equations are solved on each level, and F otherwise. This is always set to F for us.
  • LevelMethods: Set to T if different integration schemes are used on each level, and F otherwise. This is always set to F for us.
  • RestartFrame: Sets the frame from which the simulation will restart (assuming Restart is set to T). If RestartFrame is set to 0, then the simulation will restart from the last completed frame.
  • WriteFrameAtSpecifiedTime: When set to T, this forces AstroBEAR to generate an output file at a specific time. This can throw the CFL number out of whack, though, as the timestep is adjusted to finish the step by the output time. Setting this parameter to F disables forced outputs at specific times.
  • MaintainAuxArrays: It is currently read in as the MaintainAuxArrays flag. When set to T, this instructs AstroBEAR to keep track of edge-valued magnetic fields in the aux array.
  • lSink_Particles: This tag enables the code that tracks and maintains sink particles in AstroBEAR. If you are not using sink particles, you will want this to be false as sink particles carry some overhead with them.


Grid Parameters

  • nDim: The number of dimensions in the grid (for AstroBEAR, this means the number of dimensions for the problem). This value should be between 1 and 4.
  • MaxLevel: Indicates the maximum level of AMR refinement to use for this grid. MaxLevel = 2 and MaxLevel = 3 are good starting points if you're not sure how much refinement you'll need.
  • FieldVariableTolerances: An array of tolerance values for the field variables. There should never be less than MaxLevel values in this array.
  • SpatialToleranceValues: These values are intended for problems that change the shape of the cells themselves; as such, we don't typically touch them. Just make sure that there's at least MaxLevel values in this array.
  • iBuffer: The size in cells of the buffer zones to be created around each refinement area. This array should always have at least nDim elements.
  • InterpOpt: An integer array representing the interpolation option used to derive dq on each level. There should be at least MaxLevel elements in this array. The options are as follows:
    • -1 = centered: Takes the average of dqbackward and dqforward.
    • 0 = constant: Uses a constant option for dq.
    • 1 = minimod: Takes the minimum between a forward-step dq and a backward-step dq.
    • 2 = superbee: Uses a constant option for dq.
    • 3 = vanleer: Always uses the backward-step dq.
    • 4 = monotonized-centered: Always uses the forward-step dq.

Also see InterpOpt.

  • ErrorFlagOpt: An array of two-digit numbers indicating which error flag method to use for each level. See NodeInfoGlobal.f90 for more details on the values that go here. Make sure that there are at least MaxLevel entries here, as there needs to be an option for each level.
  • DomainDecomposition: The number of subdomains into which each dimension should be decomposed. This integer array should have between 1 and 4 elements, and the number of elements should always be at least nDim.
  • mx: A positive number representing the number of cells in the x dimension.
  • my: A positive number representing the number of cells in the y dimension.
  • mz: A positive number representing the number of cells in the z dimension. This field does not need to be included for 2D problems.
  • mGlobal(n): There will be nDim mGlobal entries, numbered 1 <= n <= nDim. Each one is a two-dimensional integer array representing the upper and lower bound of the grid along dimension n in the global indexing system. In most (but not all) cases, this array will be [1, mn], where n is x, y, or z.
  • nlower: There will be nDim of these fields, numbered 1 <= n <= nDim. Each of these is a scalar floating-point value representing the lower-bound of the computational domain along dimension n. Note that this is not the same as the lower bound of the grid (see mGlobal(n) above).
  • nupper: There will be nDim of these fields, numbered 1 <= n <= nDim. Each of these is a scalar floating-point value representing the upper-bound of the computational domain along dimension n. Note that this is not the same as the upper bound of the grid (see mGlobal(n) above).
  • mbc: A positive integer representing the number of ghost cells at each boundary. This value will be applied to all dimensions.
  • mthbc(n): There will be two mthbc records for each dimension, with each one containing an integer flag indicating the kind of boundary conditions along that edge of the grid (1 = extrapolated boundary conditions, 2 = periodic boundary conditions, 3 = reflecting (solid wall) boundary conditions. By version r433, 3 is for magnetic fields forced to be parallel to the boundary, and option 4 has been added for a reflecting boundary with magnetic fields forced to be normal to the boundary. A value of 999 = internal boundary conditions). These values will be read into the root node and propagated to the child [Node nodes] as they are created.
    • mthbc(1): type of boundary conditions at left
    • mthbc(2): type of boundary conditions at right
    • mthbc(3): type of boundary conditions at bottom
    • mthbc(4): type of boundary conditions at top
    • mthbc(5): type of boundary conditions at front
    • mthbc(6): type of boundary conditions at back
  • dtv(n): A floating-point value representing the initial timestep along dimension n. There will be nDim of these records (assuming nDim < 4, of course).
  • cflv(1): A floating point value representing the maximum allowable CFL number. This generally should not exceed 1.0.
  • cflv(2): A floating point value representing the desired CFL number. AstroBEAR uses this value when deciding by how much to adjust the timestep.
  • cflv(3): A floating point value representing the CFL relaxation parameter. AstroBEAR uses this value to control the rate at which a grid's current CFL number approaches the desired value (cflv(2)).
  • NrHydroVars: A non-zero integer, this is the number of hydro/MHD fields being tracked by the simulation. This is the general guideline for which variables are represented.q is the Wiki version of this page.
  • NrEllipticVars An integer giving the number of elliptic variables — actually, the number of non-hyperbolic step, non-protecting, non-source integration variables. If nonzero, these will be the last integers in q, starting at nEllipticLO and going to NrVars (where NrVars=NrHydroVars+NrEllipticVars).
  • nEquationSet: Equation set to be used on these fields. This option is only used if you intend to apply different equation sets on different grids, so we generally don't touch it.
  • maux: The number of auxiliary fields. For AstroBEAR users, this option is used when MHD is enabled and the aux array is holding edge-centered B-field values.
  • method(1): Overall integration method.
    • 0: Pencil method. Integrates along 1D "pencils" of cells.
    • 1: Sweep method. Multi-dimensional integration.
  • method(2): Selects the spatial interpolation scheme to use. A detailed description of of AstroBEAR integrations can be found here. Options are:
    • 0: First order Gudonov method.
    • 1: MUSCL primitive interpolation.
    • 2: MUSCL wave-by-wave interpolation.
    • 3: Piecewise Parabolic Method (PPM). If you choose this option, make sure that method(4) == 3. If method(1) == 1 (sweep method), then PPM == 1.
    • 4: Piecewise Hyperbolic Method (PHM).
  • method(3): Setting this flag to 1 enables direction splitting (see the integration scheme page for further details), while setting the flag to 0 disables it. This option only works for the pencil method (method(1) == 1).
  • method(4): Selects the temporal interpolation scheme. A detailed description of of AstroBEAR integrations can be found here. Options are:
    • 0: First order Gudonov method. (Not mentioned in current incarnation of bear.data)
    • 1: MUSCL-Hancock predictor-corrector method.
    • 2: TVD-preserving Runge-Kutta method.
    • 3: Piecewise Parabolic Method (PPM).
    • 4: Linear characteristic tracing. Ignored by sweep method.
  • method(5): Controls whether or not to use Strang splitting. Options are:
    • 0: No source terms.
    • 1: Use the full time step. Not supported by sweep method.
    • 2: Use Strang splitting.
  • method(6): Selects the flux handling method. Again, a more detailed description can be found here. Options are:
    • 0: Roe Flux. (For sweep method, 0 is HLLC/HLLD/HLLC_ISO/HLLD_ISO depending on iCooling and lMHD.)
    • 1: Adapted Marquina Flux. (For sweep method, 1 is exactRS.)
    • 2: Marquina Flux (hydro-only).
    • 3: HLLD Riemann solver (MHD only). (For sweep method, 3 is HLL.)
  • method(7): This option is not typically used in an AstroBEAR simulation and should remain set to 0.
  • mwaves: An integer value for the number of waves used by the Riemann solver. The recommended default is 7 (minmod), or 8 (superbee) if a highly-diffusive wave number is desired. Should match NrHydroVars. (Ignored by sweep method.)
Note: See TracWiki for help on using the wiki.