Discretization
AURORA uses four discretizations that together determine what the model resolves and how expensive it is to run:
- the
AltitudeGridwhich resolves vertical structure in the ionosphere, - the
EnergyGridwhich resolves the electron energy distribution, - the
PitchAngleGridwhich resolves the angular distribution into beams, - and the simulation time grid which controls saved output times, and also the finer internal solver steps in time-dependent runs.
The first three are part of the AuroraModel object. The time grid belongs to the AuroraSimulation and depends on whether you run a single-step steady-state, a multi-step steady-state, or a fully time-dependent simulation.
The resolution of the grids affect how well we capture different physics:
- altitude resolution controls how well sharp vertical structures are captured
- energy resolution controls how smoothly energy loss and cascading are represented
- pitch-angle resolution controls how well anisotropy and scattering are represented
- time resolution controls saved cadence, internal stability and how accuratly rapid changes are resolved
Increasing the resolution/size of these grids will improve the accuracy/fidelity of the simulations, but will also lead to longer runtimes. A balance between the two need to be found.
Altitude grid
The altitude grid is built from the altitude limits passed to AuroraModel, for example AuroraModel([100, 500], ...). The default internal grid is constructed with:
- uniform 150 m spacing below 100 km,
- nonuniform spacing above 100 km, with coarser and coarser steps as altitude increases
- but with a maximum spacing capped by
dz_max(25 km by default).
The spacing can be inspected with model.altitude_grid.Δh.
Energy grid
The energy grid is controlled by the E_max argument passed to AuroraModel. The default internal grid is piecewise non-uniform, with:
- a constant step size (~ 11.65 eV) above 500 eV to resolve ionization collisions
- finer and finer step sizes under 500 eV, down to 0.15 eV at 2eV, to resolve variations around the inelastic collisions thresholds
The energy grid is defined by:
E_edges: bin edgesE_centers: bin centersΔE: bin widths
and can inspected from model.energy_grid.
The requested E_max will be used as a constrain on the final bin center, i.e. E_centers[end] will be always ≤ E_max. This means that the last bin edge E_edges[end] can lie above E_max.
Pitch-angle grid
The pitch-angle grid construction is controlled by θ_lims, for example 180:-10:0.
These values are beam edges, not beam centers. AURORA requires:
θ_limsto include180and0- and the values to be provided in descending order
The transport equation is written in terms of the pitch-angle cosine μ = cos(θ), so the grid also stores:
μ_lims, the cosine of the angle limitsμ_center, the effective beam centers used by the transport solver
These are available from model.pitch_angle_grid.
Time grid
The time grid is part of the simulation setup rather than the model discretization itself.
There are three relevant cases:
SingleStepConfig: one steady-state solve, no time evolutionUniformTimeGrid: multiple saved times in steady-state mode, where each time point is solved independentlyRefinedTimeGrid: time-dependent mode, where the save cadence is internally refined to satisfy the CFL condition
For time-dependent simulations, sim.time.dt is the saved output cadence. The solver then derives a smaller dt_internal based on the CFL condition and solves over it. The simulation will be partitioned into several loops (n_loop) if needed so the working arrays stay within the memory (RAM) budget.
Expect dt_internal to become much smaller than dt in time-dependent runs, especially for runs with a high E_max energy (faster electrons motion will require a finer internal time grid).
The time grid configuration can be inspected from the simulation object sim.time.
Matching external inputs to the model grids
When loading external fluxes from a file, the file dimensions must match the model grids used by the simulation. In particular, AURORA does not interpolate in pitch angle or energy when reading file-based fluxes, so the file must be prepared on the same beam and energy grid as the target model.
The safest workflow is:
- build the
AuroraModelwith the settings you plan to simulate, - read
model.pitch_angle_grid.μ_centerandmodel.energy_grid.E_centers, - write the external file on those exact grids.
See the Input Flux tutorial for the concrete file format and loading workflow.