A Brief Lesson in 2.5D

A couple of weeks ago, I learned how to run a 2.5D (axisymmetric cylindrical coordinates) simulation in astrobear. More recently, I learned about geometric source terms in general, and how astrobear actually accomplishes its transformation to 2.5D. This blog post is a brief summary of what I learned and is intended as an introduction for the naive user…


The 2.5D Source Term for Mass Conservation

To illustrate the concept of geometrical source terms, it suffices to look at mass conservation in 2D and 2.5D. As you already know, the mass conservation equation can be written as: First, we move the flux term to the other side and use a product rule: Now, we can simplify the right hand side using 2D Cartesian coordinates: Now, we can simplify eq. (1) again but this time in axisymmetric Cylindrical coordinates. Axisymmetry just means that there is no dependence on phi, so those terms from the del operator go to 0. So eq. (1) now becomes: This can be simplified further with a product rule: If you compare equations (2) and (3), the meaning of a geometrical source term is realized. The flux terms are essentially the same (just in different directions), but switching to cylindrical coordinates introduces an extra source term Similar derivations can be done for the other conservation equations to get more geometrical source terms. Those can get slightly more complicated when you allow for rotation (velocity in phi direction), and if you have magnetic fields. You could also derive geometrical source terms for other coordinate systems.


How AstroBEAR Handles 2.5D

Switching on 2.5D is quite simple; you just set iCylindrical in physics.data. 0 is off, 1 is for without rotation (aka angular momentum) , and 2 is for with rotation. When iCylindrical is 1 or 2, astrobear treats the x-axis as the r-axis and the y-axis as the cylindrical z-axis. When you look back at equations (2) and (3), you can see why mapping x —> r and y —> z makes a lot of sense. This information is also explained in PhysicsDataExplained.

Now, when astrobear is actually solving the hydro (or MHD) equations, it uses a Runge-Kutta method. Those methods can get somewhat involved, but in our case, they are basically used to solve equations of this form: where change is a time derivative, fluxes are spatial derivatives, and sources are everything else. These methods do not care if the flux terms are in the x direction or r direction; they are just generic flux terms. So the only thing that astrobear has to do differently for 2.5D is add the geometrical source terms to the dqdt-array (the array that represents the time derivative of q). This step is done in the function SrcDerivs in source_control.f90, and the actual cylindrical source terms are defined in cylindrical.f90. If you look at cylindrical.f90 you will see all of the source terms for all of the variables in the dqdt-array (including the one I derived above). Note that source terms also have to be added to any tracers that might be present, and tracers are handled just like density.


Cylindrical Coordinates in Athena

This is the paper that Jonathan was referring to. It is about implementing cylindrical coordinates in the Athena code. The paper mentions the geometrical source terms that I discussed, but includes MHD and rotation (also, in primitive form rather than conservative). The bulk of the paper is focused on how to do the reconstruction in cylindrical coordinates without changing the Riemann solvers. This definitely looks like something we could do for astrobear. http://adsabs.harvard.edu/abs/2011ASPC..444..260S

Comments

No comments.