How to setup a problem in AstroBEAR

Think about the physical system you want to simulate

• What is the typical number density n, temperature T, magnetization B, and size scale L_{Box} of the system and what types of flow speeds V do you expect.
• What is the cooling length L_c, jeans length L_J, diffusion length, etc…
• If the cooling length L_c is much less than the cell size \Delta x, an isothermal equation of state may be appropriate. If L_c >> L_{Box} then cooling may not be important.
• Likewise if the L_J >> L_{Box} self-gravity may not be important.
• Is ambi-polar 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 H-viscosity 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 B_x(-x) = -B_x(x) and B_y(-x) = B_y(x) and B_z(-x) = B_z(x)
    • The bottom boundary should be REFLECT_BPARALLEL = 4 to keep field lines normal to it. This sets B_x(-y)=-B_x(y) and B_y(-y)=B_y(y) and B_z(-y)=-B_z(y).
    • Note it the x-axis were REFLECT_BPARALLEL this would be B_x(-x)=B_x(x), B_y(-x)=-B_y(y), and B_z(-x)=-B_z(x)
  • 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 P_z(-x)=-P_z(x).
  • 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 non-infinite 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 run-away 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 1e-300 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, free-fall 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

Additional information can be found on this discussion forum thread, ​here.

BackLinks