Version 4 (modified by 12 years ago) ( diff )  ,

How to setup a problem in AstroBEAR
Think about the physical system you want to simulate
 What is the typical number density , temperature , magnetization , and size scale of the system and what types of flow speeds do you expect.
 What is the cooling length , jeans length , diffusion length, etc…
 If the cooling length is much less than the cell size , an isothermal equation of state may be appropriate. If then cooling may not be important.
 Likewise if the selfgravity may not be important.
 Is ambipolar diffusion important, radiation pressure, etc… If so, you may have to wait for new physics to be put in AstroBEAR
Below is an image showing various parameters in astrophysically convenient scales. These curves assume the gas is in thermal equilibrium using the Inuoue and Inutsuka curve. This figure was generated in matlab using selfgrav.m
Think about the types of instabilities you expect to see
 Gravitational instability
 Thermal instabilities
 Thin shell instabilities
 Rayleigh Taylor instabilities
 Kelvin Helmholtz instability
Since many instabilities grow faster on the smallest scale, it is usually better to seed the instabilities with a prescribed perturbation, rather then let the numerical noise (especially at AMR boundaries) determine the evolution of the system. It may be necessary to enforce refinement in the area surrounding an interfaces to prevent this effect  or lower the refinement tolerances enough to reduce this error. In some instances Hviscosity may be needed to suppress the Carbuncle instability.
Think about the geometry of the problem and any symmetries that can be exploited to speed up computation.
 Does your initial setup possess any reflective symmetry that could be exploited to speed up the computation?
 If so, reflective boundary conditions can be used although one needs to be careful with magnetic fields…
 Consider a poloidal field configuration in 2D. If you just look at the magnetic field lines (ignoring the direction), it has reflective symmetry in both the x and y direction. However, if you include the direction of the field lines  the y symmetry is modified (much like a pseudo vector). AstroBEAR supports both types of boundaries.
 The left boundary should be REFLECT_WALL = 3 to keep field lines from crossing it. This sets and and
 The bottom boundary should be REFLECT_BPARALLEL = 4 to keep field lines normal to it. This sets and and .
 Note it the xaxis were REFLECT_BPARALLEL this would be , , and
 Both of these cases also reflect the normal component of the momentum. However in 2.5D you also want to reflect the component of momentum normal to the page… So in 2.5D, the left boundary would be REFLECT_CYLINDRICAL. This is essentially REFLECT_WALL, but with .
 In any case you should also be aware of any instabilities that would normally destroy the symmetry since these will be supressed ie..
 Magnetized jets kinking
 Other azimuthal instabilities (clump shredding)
 Does your problem possess translational invariance? If so you could shrink your domain and use periodic boundary conditions.
 Just as using 2.5D to simulate a truly 3D system can suppress instabilities and lead to different behavior  using periodic boundary conditions to simulate a noninfinite system  can lead to modified behavior.
 2D or 3D
 2D simulations do not allow for any vortex stretching  So turbulence in general will be quite different in 3D then in 2D. (In 2D you end up with an inverse cascade of eddies from small to large scales where in 3D the cascade is from large to small scales.)
Extrapolating Boundary Conditions
 Extrapolating boundary conditions are in general unphysical  and should only technically be used when it can be guaranteed that the flow will always be leaving the grid supersonically. However it is often ok as long as the flow is not entering the grid. If material enters the grid at an interpolating boundary condition  then information is traveling both upstream and downstream and a type of feedback is possible which can result in runaway growth… Problems with gravitational sources are particularly susceptible to extrapolating boundary conditions and if extrapolating boundary conditions are used  there should be checks to ensure that there is never any inflow at an extrapolated boundary condition.
User Specified Boundaries
 When there are jets or winds  it is in general better to explicitly set the ghost zones rather than relying on extrapolating boundaries to maintain an initial wind or jet profile. With magnetic fields you cannot just set aux fields without introducing divergence  however as long as you only step on the aux fields in the ghost regions and don't modify any of the aux zones that are internal to the grid ie.
aux(1:mx+1, 1:my, 1:mz, 1), aux(1:mx, 1:my+1,1:mz,2), aux(1:mx, 1:my, 1:mz+1,3)
it should not create problems
 Alternatively you could use reflective boundary conditions for the field to keep the field lines normal (4) or parallel (3) to the boundary and only step on the fluid variables (density, momentum, energy)…
Computation Scales
In general the computational scales you set in physics.data are not that important and should not effect the simulation at all (unless you're scaled values are below 1e300 or greater than 1e300 in which case double precision values will have under/over flow issues)  however careful choices can help in understanding the results… For example if nScale is chosen to be the ambient density and lScale is chosen to be the box size and tScale is chosen to be the runtime  then ScaleGrav immediately tells you how important gravity is etc… From a theoretical point of view it is often convenient to scale density, length, and time to physically motivated values (ie jeans length, mean density, freefall time) etc… since it is convenient to think about values in these units. From an observational point of view, however, it is often convenient to use an nScale of 1, a TempScale of 1 and an lScale of either 1pc ~ 3e19 cm or 1AU ~ 1.5e18 cm depending on the problem. You could also use a rhoScale of 1, a pScale of 1, and an lScale of 1 if you wanted your data files to be in cgs units. For more help on working with computational scales see SimulSetup
Attachments (2)

astro_scales.png
(16.4 KB
)  added by 13 years ago.
Image showing typical astrophysical scales

selfgrav.m
(800 bytes
)  added by 13 years ago.
Matlab file for generating picture
Download all attachments as: .zip