Computation Scales

Units in Astrobear

Astrobear can use arbitrary computational units for length, mass, time, etc… These are derived from specifying 4 of the following in physics.data

• nScale - Number density
• rScale - Mass density
• TempScale - Inverse Gas constant \frac{\rho T}{P}
• pScale - Pressure
• TimeScale - Time
• lScale - Length
• Xmu - Mean atomic mass (in amu)

The 4 specified must be independent. Specifying nScale, rScale and Xmu will result in an error - since there is a single equation linking just those three. Likewise specifying nScale, pScale, and TempScale will result in an error.

Electromagnetism

For electromagnetic units, Astrobear uses something like rationalized electromagnetic units (extra factor of \sqrt{4 \pi} in the electric and magnetic fields) - or Lorentz-Heaviside but scaling the E field by c and the charge density \rho (and current J ) by \frac{1}{c}. This avoids the need for any additional multiplication by factors of c.

Computational	Lorentz-Heaviside	Gaussian
E	c E^{LH}	\frac{c }{\sqrt{4\pi}}E^{G}
\rho	\frac{1}{c}\rho^{LH}	\frac{\sqrt{4 \pi} }{c}\rho^{G}
J	\frac{1}{c} J^{LH}	\frac{\sqrt{4 \pi}}{c} J^{G}
B	B^{LH}	\frac{1}{\sqrt{4\pi}} B^{G}

Using the approach in the appendix of Jackson, we have

k_1 = \frac{c^2}{4 \pi}

k_2 = \frac{1}{4\pi}

k_3 = 1

\alpha = 1

\mu_0 = 1

\epsilon_0 = \frac{1}{c^2}

This allows us to write Maxwell's equations as

\nabla \cdot \mathbf{E} = c^2 \rho

\nabla \times \mathbf{B} = \mathbf{J} + \frac{1}{c^2} \frac{\partial \mathbf{E}}{\partial t}

\nabla \times \mathbf{E} = - \frac{\partial \mathbf{B}}{\partial t}

\nabla \cdot \mathbf{B} = 0

as well as

Lorentz Force Law	\mathbf{F} = q \left ( \mathbf{E} + \mathbf{v} \times \mathbf{B} \right)
Coulomb's Law	\mathbf{F} = -\frac{c^2}{4 \pi} \frac{q_1 q_2}{r^2}\hat{\mathbf{r}}

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

Astrophysical problems involve many different physical units and constants with a wide range of scales. To avoid the loss of precision that comes when computers try to work with, say, a 10^-8 variable and a 10²⁴ constant in the same expression, we scale our units into computational units before storing them in the data arrays.

Usually, the physical scales are defined in the physics.data file—you simply enter the scales for density, temperature, velocity, etc in that file, and AstroBEAR will read them in. More complicated scaling would be defined in the ProblemModuleInit() routine (see above).

You have two options for making sure that you only put scaled quantities in the data arrays: you can scale your input values before you enter them into your input file (and then assume that you are reading in scaled quantities), or you can use physical quantities in your input files and then scale them within your problem module

BackLinks