| 37 | | |
| 38 | | * '''!ProblemModuleInit():''' Module variables are initialized here. This routine is where {{{problem.data}}} are read in and module-level namelists are populated. {{{ProblemModuleInit()}}} is also a popular place to put sanity checks that verify the correctness of all inputs. {{{ProblemModuleInit()}}} is also a common place to initialize source terms. |
| 39 | | |
| 40 | | * '''!ProblemGridInit(Info):''' This is where you initialize the data arrays. Remember that this routine is getting called on a grid-by-grid basis, so attempts to initialize data outside this grid will probably cause a segfault. For an example routine see ProblemGridInit |
| 41 | | |
| 42 | | * '''!ProblemBeforeStep(Info):''' The before-step subroutine. This procedure is called before each time-step of the simulation, so that the driving mechanisms specified by the user can be reapplied at each step. For example, a jet simulation would inject new material into the system during {{{ProblemBeforeStep()}}}. Note that no integration occurs during this step; this is just where new conditions are introduced (and sometimes renewed). If you have no special pre-step needs, then leave this routine as a stub. |
| 43 | | |
| 44 | | * '''!ProblemAfterStep(Info):''' The after-step subroutine. This procedure is called following each time step of a system. This is perhaps the least commonly used of the control subroutines, but divergence cleaning, special output files, and other post-processing operations could be performed here. If you have no special post-step instructions, then just leave this routine as a stub. |
| 45 | | |
| 46 | | * '''!ProblemSetErrFlag(Info):''' Flags regions where this module requires additional resolution. If you do not have any special refinement needs, then just leave this routine as a stub. |
| | 37 | The six subroutines can be split into two groups |
| | 38 | ==== Those that modify an individual AMR patch ==== |
| | 39 | Note these may get called multiple times on a given processor or not at all depending on how patches are distributed among the processors. '''''The only assignment statements should be for variables local to each subroutine or the fluid data belonging to the info patch. Do not modify module variables or global variables within these subroutines.''''' |
| | 40 | * '''!ProblemGridInit(Info):''' This is where you initialize the data arrays. Remember that this routine is getting called on a grid-by-grid basis, so attempts to initialize data outside this grid will probably cause a segfault. For an example routine see ProblemGridInit |
| | 41 | * '''!ProblemBeforeStep(Info):''' The before-step subroutine. This procedure is called before each time-step of the simulation, so that the driving mechanisms specified by the user can be reapplied at each step. For example, a jet simulation would inject new material into the system during {{{ProblemBeforeStep()}}}. Note that no integration occurs during this step; this is just where new conditions are introduced (and sometimes renewed). If you have no special pre-step needs, then leave this routine as a stub. |
| | 42 | * '''!ProblemAfterStep(Info):''' The after-step subroutine. This procedure is called following each time step of a system. This is perhaps the least commonly used of the control subroutines, but divergence cleaning, special output files, and other post-processing operations could be performed here. If you have no special post-step instructions, then just leave this routine as a stub. |
| | 43 | * '''!ProblemSetErrFlag(Info):''' Flags regions where this module requires additional resolution. If you do not have any special refinement needs, then just leave this routine as a stub. |
| | 44 | ==== And those that get called on by every processor at certain times. ==== |
| | 45 | Note here you can adjust module variables or modify the properties of [AstroBearObjects Objects]. You can also add global communication here if you desire though this is usually not necessary. |
| | 46 | * '''!ProblemModuleInit():''' Module variables are initialized here. This routine is where {{{problem.data}}} are read in and module-level namelists are populated and is called once per processor at the start (or restart) of a simulation. {{{ProblemModuleInit()}}} is also a popular place to put sanity checks that verify the correctness of all inputs. {{{ProblemModuleInit()}}} is also a common place to initialize source terms. |
| | 47 | * '''!ProblemBeforeGlobalStep(level):''' This is called by every processor one per step per AMR level. If you need to modify variables other than the grid data - this is the correct place to do so. If you are using threading however - you should only modify variables between root steps (when level == 0). |
| | 48 | |
| 62 | | There are two major data arrays in {{{InfoDef}}}: the {{{q}}} array and the {{{aux}}} array. {{{q}}} holds the cell-centered data and is used by all AstroBEAR simulations. The {{{q}}} array takes the form {{{q(x,y,z,variable)}}} where {{{variable}}} is itself a 1D array that holds the physical quantities such as density, momentum, energy, etc. The order of the quantities in the {{{variable}}} array is {{{(rho, px, py, pz, E)}}}. An integer or a specific character can be used for {{{variable}}}. The characters that can be used are {{{irho, ivx, ivy, ivz, iE}}} respectively. So for example, the following two statements are equivalent: |
| 63 | | {{{ |
| 64 | | Info%q(x,y,z,3) = 2.0 |
| 65 | | |
| 66 | | Info%q(x,y,z,ivy) = 2.0 |
| 67 | | }}} |
| 68 | | They both place the value 2.0 into the position in {{{q}}} that is reserved for the y-component of momentum. Note that in order to use these character indices, the following statement is required at the beginning of {{{problem.f90}}}: |
| | 64 | There are two major data arrays in {{{InfoDef}}}: the {{{q}}} array and the {{{aux}}} array. {{{q}}} holds the cell-centered data and is used by all AstroBEAR simulations. The {{{q}}} array takes the form {{{q(x,y,z,variable)}}} where {{{variable}}} is an index that refers to the various physical quantities such as density, momentum, energy, etc. in each cell. The order of the quantities in the {{{variable}}} array is dependent on the equation of state, whether or not magnetic fields are being tracked, etc... For 2D hydro (non MHD) the order of the fields is {{{(rho, px, py, E)}}}. So if we wanted to set the energy of the cell at integer location {{{i,j,k}}} we would use |
| | 65 | {{{ |
| | 66 | Info%q(i,j,k,4) = 1.0 |
| | 67 | }}} |
| | 68 | However if we were to change the number of dimensions from 2 to 3, then the order of the fields would be {{{rho, px, py, pz, E}}} and the above statement would not set the energy, but the z momentum to 1.0 and leave the energy unchanged. The solution is to avoid using integer constants for the 4th array index and instead use integer variables that are adjusted based on the equations of state, number of dimensions, etc... These variables are declared in {{{PhysicsDeclarations}}} so we need to also add |
| 72 | | }}} |
| | 72 | }}} |
| | 73 | to the top of our module. Then we can set the energy of cell {{{i,j,k}}} regardless of the specifics of our problem by using |
| | 74 | {{{ |
| | 75 | Info%q(i,j,k,iE) = 1.0 |
| | 76 | }}} |
| | 77 | Also, if we happen to be using an isothermal equation of state, then the energy is no longer stored within the q array and the value of iE is set to 0 to indicate this. So it is generally a good idea to check the value of iE as follows |
| | 78 | {{{ |
| | 79 | IF (iE /= 0) Info%q(i,j,k,iE)=1.0 |
| | 80 | }}} |
| | 81 | |
| | 82 | Additional variables used to store slots are: |
| | 83 | * irho - density (always non-zero) |
| | 84 | * ivx - x momentum (always non-zero) |
| | 85 | * ivy - y momentum (non-zero unless 2D, 3D, MHD) |
| | 86 | * ivz - z momentum (non-zero unless 3D, MHD) |
| | 87 | * iE - Energy (non-zero unless isothermal EOS) |
| | 88 | * iBx - x magnetic field (non-zero unless MHD) |
| | 89 | * iBy - y magnetic field (non-zero unless MHD) |
| | 90 | * iBz - z magnetic field (non-zero unless MHD) |
| | 91 | |
| | 92 | There are also two arrays that are sometimes useful as well |
| | 93 | * iB(1:3) = (/iBx, iBy, iBz/) |
| | 94 | * imom(1:3) = (/ivx, ivy, ivz/) |
| 79 | | Currently, AstroBEAR can only run 2D and 3D problems, but a 1D hydro or MHD problem can be simulated by defining a very narrow 2D problem domain and then making sure all the activity is defined in the x-direction (i.e., no {{{py}}} or {{{pz}}} components). |
| 80 | | |
| 81 | | The ''core'' region of the {{{Info%q}}} array (which does not include ghost zones) is a {{{1:mx}}} by {{{1:my}}} by {{{1:mz}}} box. mx, my, and mz denote the number of cells in the x, y, and z directions, respectively. In two dimensions, {{{mz}}} = 1, reducing the box to a rectangle. {{{Info%q}}} is cell-centered, so the values are assumed to be taken from the midpoint of the cell. Thus, the cell-to-space conversion is: |
| 82 | | |
| 83 | | {{{ |
| 84 | | x=(xlower + (REAL(i,xPrec)-half) * dx) |
| | 101 | The ''core'' region of the {{{Info%q}}} array (which does not include ghost zones) is {{{Info%q(1:Info%mx(1),1:Info%mx(2),1:Info%mx(3),1:NrHydroVars)}}} where {{{Info%mx(1)}}}, {{{Info%mx(2)}}}, and {{{Info%mx(3)}}} denote the number of cells in the x, y, and z directions, respectively and {{{NrHydroVars}}} represents the number of fluid variables including tracers. If running with fewer than 3 dimensions, the unused dimensions have an extent of 1. |
| | 102 | |
| | 103 | Before we can initialize a cell we must calculate it's physical location and extent. To do so we need to know the cell size for the Info's AMR level. |
| | 104 | |
| | 105 | {{{Info%q}}} is cell-centered, so the values are assumed to be taken from the midpoint of the cell. The lower bounds of the info patch for the x, y, and z direction are given by the components of the array {{{Info%xBounds(1:3,1)}}}. And the cell size is given by {{{levels(Info%level)%dx}}}. Thus, the index-to-space conversion is: |
| | 106 | {{{ |
| | 107 | x=Info%xBounds(1,1) + (REAL(i,xPrec)-half) * levels(Info%level)%dx) |
