2.3 Dimensional or non-dimensionalized equations?
Equations (1)–(3) are stated in the physically correct form. One would usually interpret them
in a way that the various coefficients such as the viscosity, density and thermal conductivity
are
given in their correct physical units, typically expressed in a system such as the meter, kilogram, second (MKS)
system that is part of the SI system. This is certainly how we envision ASPECT to be used: with
geometries, material models, boundary conditions and initial values to be given in their correct physical
units. As a consequence, when ASPECT prints information about the simulation onto the screen, it
typically does so by using a postfix such as m/s to indicate a velocity or W/m^2 to indicate a heat
flux.
Note: For convenience, output quantities are sometimes provided in units meters per year instead
of meters per second (velocities) or in years instead of seconds (the current time, the time
step size); this conversion happens at the time output is generated, and is not part of the
solution process. Whether this conversion should happen is determined by the flag “Use years
in output instead of seconds” in the input file, see Section ??. Obviously, this conversion
from seconds to years only makes sense if the model is described in physical units rather than in
non-dimensionalized form, see below.
That said, in reality, ASPECT has no preferred system of units as long as every material constant, geometry,
time, etc., are all expressed in the same system. In other words, it is entirely legitimate to implement geometry and
material models in which the dimension of the domain is one, density and viscosity are one, and the
density variation as a function of temperature is scaled by the Rayleigh number – i.e., to use the usual
non-dimensionalization of the equations (1)–(3). Some of the cookbooks in Section 5 use this non-dimensional
form; for example, the simplest cookbook in Section 5.2.1 as well as the SolCx, SolKz and inclusion
benchmarks in Sections 5.4.4, are such cases. Whenever this is the case, output showing units m/s or
W/m^2 clearly no longer have a literal meaning. Rather, the unit postfix must in this case simply be
interpreted to mean that the number that precedes the first is a velocity and a heat flux in the second
case.
In other words, whether a computation uses physical or non-dimensional units really depends on the geometry,
material, initial and boundary condition description of the particular case under consideration – ASPECT will
simply use whatever it is given. Whether one or the other is the more appropriate description is a decision we
purposefully leave to the user. There are of course good reasons to use non-dimensional descriptions of realistic
problems, rather than to use the original form in which all coefficients remain in their physical units. On the other
hand, there are also downsides:
- Non-dimensional descriptions, such as when using the Rayleigh number to indicate the relative strength
of convective to diffusive thermal transport, have the advantage that they allow to reduce a system to
its essence. For example, it is clear that we get the same behavior if one increases both the viscosity and
the thermal expansion coefficient by a factor of two because the resulting Rayleigh number; similarly,
if we were to increase the size of the domain by a factor of 2 and thermal diffusion coefficient by a
factor of 8. In both of these cases, the non-dimensional equations are exactly the same. On the other
hand, the equations in their physical unit form are different and one may not see that the result of this
variations in coefficients will be exactly the same as before. Using non-dimensional variables therefore
reduces the space of independent parameters one may have to consider when doing parameter studies.
- From a practical perspective, equations (1)–(3) are often ill-conditioned in their original form: the
two sides of each equation have physical units different from those of the other equations, and their
numerical values are often vastly different.
Of course, these values can not be compared: they have different physical units, and the ratios between
these values depends on whether we choose to measure lengths in meters or kilometers, for example.
Nevertheless, when implementing these equations in software, at one point or another, we have to work
with numbers and at this point the physical units are lost. If one does not take care at this point,
it is easy to get software in which all accuracy is lost due to round-off errors. On the other hand,
non-dimensionalization typically avoids this since it normalizes all quantities so that values that appear
in computations are typically on the order of one.
- On the downside, the numbers non-dimensionalized equations produce are not immediately comparable
to ones we know from physical experiments. This is of little concern if all we have to do is convert
every output number of our program back to physical units. On the other hand, it is more difficult
and a source of many errors if this has to be done inside the program, for example, when looking up
the viscosity as a pressure-, temperature- and strain-rate-dependent function: one first has to convert
pressure, temperature and strain rate from non-dimensional to physical units, look up the corresponding
viscosity in a table, and then convert the viscosity back to non-dimensional quantities. Getting this
right at every one of the dozens or hundreds of places inside a program and using the correct (but
distinct) conversion factors for each of these quantities is both a challenge and a possible source of
errors.
- From a mathematical viewpoint, it is typically clear how an equation needs to be non-dimensionalized
if all coefficients are constant. However, how is one to normalize the equations if, as is the case in the
earth mantle, the viscosity varies by several orders of magnitude? In cases like these, one has to choose
a reference viscosity, density, etc. While the resulting non-dimensionalization retains the universality
of parameters in the equations, as discussed above, it is not entirely clear that this would also retain
the numerical stability if the reference values are poorly chosen.
As a consequence of such considerations, most codes in the past have used non-dimensionalized models. This was
aided by the fact that until recently and with notable exceptions, many models had constant coefficients and the
difficulties associated with variable coefficients were not a concern. On the other hand, our goal with ASPECT is
for it to be a code that solves realistic problems using complex models and that is easy to use. Thus, we allow users
to input models in physical or non-dimensional units, at their discretion. We believe that this makes the description
of realistic models simpler. On the other hand, ensuring numerical stability is not something users should have to be
concerned about, and is taken care of in the implementation of ASPECT’s core (see the corresponding section in
[KHB12]).