Currently the model saves bolometric fluxes, but saving spectral ones (i.e. per band) would be very helpful also.

There are currently two ways to change parameters:

1. Edit the script you are running
2. Use the command line interface

Neither of these save values to the disk, so it's impossible to know what values were used to generate a given result once the script has been changed or the terminal session closed. Adding a write_cfg function would be useful not only for development, but also for ensuring that the results are replicable.

Currently I am using pre-made spectral files taken from the AEOLUS repository. It would be good to include such tools in this project, even if they're duplicated.

Similarly, it's important to create spectral files which use cross-sections from HITEMP or Exomol, at least for comparison with HITRAN cases.

Adding a subroutine for calculating the contribution function at each level of the atmosphere. This requires knowing the optical depth at each pressure level.

The contribution function can be calculated according to:
https://ui.adsabs.harvard.edu/abs/1998Sci...282.2063G/abstract
https://ui.adsabs.harvard.edu/abs/2016A%26A...594A..69D/abstract

AGNI should be able to take an array of heating rates and/or fluxes as an additional source of energy transport that can't be calculated self-consistently within the model. This would be loaded from a csv or netcdf file, and be applied to the HR/residual array at solve-time.

Examples of these external heatings include:

• Advective heat transport (e.g in RCAE models)
• Enthalpy from disequilbrium chemistry
• Joule heating from magnetic effects
• Frictional/dissipative heating from tidal effects

Currently, the model uses a fixed value for latent heat of vapourisation. Given that this quantity is temperature-dependent, it would improve the model accuracy to evaluate it consistently at runtime.

With my new tools for creating arbitrary spectral files, we now have more control over the number of bands used in the RT calculations. A significant optimisation to AGNI would be to dynamically switch the spectral file at run-time (at some time-cost). This would be done as follows:

1. Initialise T(p) with first guess and load semi-grey spectral file (3 bands)
2. Iterate rapidly for a while until we are somewhat closer to the solution.
3. Switch to medium-resolution spectral file (~200 bands) to obtain solution.
4. Switch to high-resolution spectral file (~4000 bands) to refine solution and generate nice spectra.

This comes with benefits to both performance and accuracy.

The energy balance is set by: surface temperature, instellation, zenith angle θ , an ASF scale factor s.

Setting the first two is easy. Choosing the last two is more tricky. We can refer to previous works for a discussion in what choices are most appropriate (e.g. Hamano+13, Cronin+14), but a self-consistent calculation would be great.

This would involve calculating θ and s appropriately, provided with the parameters for: planetary rotation rate, planet radius, orbital period, latitude, obliquity, and averaging scheme. The latter of which describes how we are averaging the 3D planet into a 1D column.

Maybe a monte-carlo approach would work, but it shouldn't need to invoke any RT.

This would be better than just adding comments into the code.

SOCRATES calculates the optical depth per-band and as a grey quantity. It would be useful to know tau vs pressure for analysis of the outputs from the model, although extracting this from SOCRATES seems to be somewhat tricky.

Currently, the gases included in the model need to be supported both by SOCRATES and the spectral file provided. For the mixing ratios to sum to unity, this requires neglecting unsupported gases and renormalising the VMRs.

As a result, requesting unsupported gases effectively enhances the partial pressures of all other gases. This is not physical, since it acts to increase their absorption without physical justification.

It would be better to handle missing gases by treating them as "transparent absorbers". That is, include them in all calculations but set their opacity to zero. This would allow the VMRs to sum to unity without dropping any gases, and would not introduce extra opacity.

This is related to Issue #16.

The benefit of a radiative-convective model is that it can more accurately predict which layers are convective and which are purely radiative. Therefore, it's important to factor in the effect of convective inhibition. This could be implemented into AGNI alongside Issue #24.

The condensation scheme currently requires you to specify a characteristic "timescale" over which the condensation occurs. This is important in determining how easily T can drop below T_dew for a given gas, being forced by radiative cooling or other transport processes.

In reality, this is set by the microphysics of the system, but typically the timescale will shrink as the amount of supersaturation increases. There's also a factors depending on the droplet size(s), the available condensation nuclei, and so on.

It would be interesting to implement a (simple!!) microphysical model of condensation into AGNI, which (I think) would fit relatively easily into the current formulation.

AGNI is a 1D column model. It would be interesting to include multiple (equatorial) columns at different longitudes. This would allow some amount of heat transport around the planet, although the efficiency of the dynamical processes would have to be parameterised.

This could be done by creating and storing multiple atmos structs, but using a single solver.

JANUS is no longer packaging SOCRATES, and instead assumes that the user has installed it elsewhere already. We could do the same thing for AGNI for consistency, making SOCRATES a "dependency" of the code rather than an integrated part of it.

This will also make testing and building things much easier.

Sometimes the NR method struggles to converge the "final result", instead it bounces around it. This is particularly problematic when convection extends from the surface, which is expected to be common for many systems.

Since the NR method profiles a descent direction x_dif, we can scale this vector to obtain an optimal step size by using a line search method. I've already found that scaling this factor by 0.1x works well to improve model performance in some cases.

This should be relatively simple to implement:

1. Start at x = x_old with residuals r = r_old
2. Calculate NR step, providing x_dif and r_tst residuals
3. Sample r_tst for various x = x_old + a * x_dif, where a is varied within the semi-closed interval (0,1].
4. Select the best value of a (and thus the new x) based on the optimal r_tst.
   We could probably just use a handful of a values at each iteration, so the performance change from this should be minimal.

It would be interesting to couple AGNI to a 1D chemical model, whether that's a kinetics model or even just equilibrium chemistry. It wouldn't be too hard to do this simply by executing the other model as a subprocess.

The current state of the code is not very well optimised. I am certain there are several memory allocations and loops that can be removed or reworked.

It would also be worth considering some of the Julia optimisation macros (e.g. @simd) to enhance performance.

Neglecting moist convection may not be reasonable in some cases. To test this, it should be implemented into the model alongside dry convection and condensation (Issue #5).

Ideally this would be done by adapting the MLT approach, although it may be necessary to use adjustment.

https://link.springer.com/chapter/10.1007/978-3-642-13574-3_15

Currently:

• Heat capacities are either evaluated as constants, or through the Shomate equation (NIST coeffs.)
• Latent heats are hard coded.
• Mean molecular weight is hard coded.

This is not very extensible to a large range of molecules (i.e. from FastChem, atmodeller). Instead, the model should use lookup tables (which are fast) to calculate the heat capacity as a function of temperature. MMWs can be approximated as the sum of atomic masses (binding energy only makes a small difference). Latent heats will be more complex (Issue #11).

https://janaf.nist.gov/

The O2-N2 continuum is producing spuriously strong absorption at the red-end of its range. This is approximately from 5.3 um to 7.8 um (bands 132-152 in Honeyside256).

I have tested various gas combinations, and it seems that only this pair is impacted. I don't know why. It is derived from HITRAN, which is trustworthy, so maybe there's some issue in the spectral file generation.

As a workaround, I have disabled O2 opacities in AGNI through the variable atmosphere.BLACKLIST_RT. It is treated properly in most of the code, but the O2 mass mixing ratio passed to radiance_calc is always set to zero.

The literature source for this continuum can be found here: https://opg.optica.org/ao/fulltext.cfm?uri=ao-36-3-563&id=60415

The current disk-size for the repository is about 600 MB. This is quite large, and is broken down as:

122M	spectral_files
113M	stellar_spectra
18M	thermodynamics
112K	literature_data
24K	surface_albedo
20K	config

It would make sense to store some of the data elsewhere, to be downloaded when requested or when necessary. Only a small amount of these data need to be downloaded when cloned: a couple of spectral files, a couple of stellar spectra. The rest can stay.

It might make sense to download these from OSF: https://osf.io/vehxg/

I think it's fine that the spectra are stored as plain text files in res/, but it would be good to convert the current script src/insert_stellar.py from Python to Julia. It should also check for energy conservation when down-binning the spectra.

Constructing a jacobian is quite expensive, since it requires a lot of flux evaluations. A semi-random approach might be valuable, at least for providing an initial guess to the model.

Randomising the temperatures is one option, but maybe randomising the lapse rate (and keeping it constant at all levels) is more reasonable.

This could also be used for when the solver gets stuck in other methods.

The model includes water cloud optical properties, which seems to work well in terms of blocking LW upward flux. However, they don't seem to be scattering downwelling solar flux.

It's important that both properties are captured accurately.

The code currently uses Plots.jl for making plots. However, this library is missing several features such as symlog scales. Instead, it should use a more complete library such as Makie.jl (https://docs.makie.org/stable/).

Sometimes the Newton (etc.) solvers get stuck in a "trough" of parameter space. The Nelder-Mead method can help with this.

https://en.wikipedia.org/wiki/Nelder%E2%80%93Mead_method

Rayleigh scattering currently depends on using a Python script by RJ Graham to insert information into the spectral file. I should ensure that this is still physical, and take the opportunity to translate it into Julia.

SOCRATES is currently compiled with -O3, which is the maximum optimisation level that gfortran will safely apply.

The flag -Ofast turns on extra optimisations (such a fastmath) at the risk of numerical issues. This is worth testing.

The current command-line interface is confusing and overly complicated. There are too many parameters to reasonably pass into one command.

AGNI should instead use a configuration file, which would also allow the many execution scripts to be merged into a single script, instead having multiple configuration files.

I suggest using the TOML format.
https://docs.julialang.org/en/v1/stdlib/TOML/

Currently the model uses the ideal gas equation of state. At high pressures this becomes less valid. Incorporating a more realistic EOS (e.g. Redlich–Kwong) could make a difference to the heights, layer masses, and heating rates in the model.

The current setup is a bit too involved, so it would be better to either:

1. Make the instructions very clear, or
2. Create a makefile or script that handles everything automatically

Currently the model uses a LW boundary condition set by the surface temperature. That is, it sets the upward stream longwave flux at the surface according to some surface temperature (Tstar).

Most other models (e.g. HELIOS) instead set the net upward-directed longwave flux at the bottom-most level. They then express this as an internal temperature Tint (through σT^4).

For comparison with other models, it would be useful to include the latter boundary condition as an option. This can be done by simply adjusting the current configuration (Tstar) according to:
σTint^4 = σTstar^4 - S - F
where S and F are the downward-directed solar and thermal streams respectively.

Condensation is important as it prevents the temperature dropping below the dew point temperature. Including this in the time-stepping solver is easy, but including it into the nonlinear solver is more tricky.

Maybe one way to do this is to set the power dissipation (i.e. F_bot-F_top across a cell) to be strictly positive when T<=T_dew.

With AGNI now formulated as a package, it should be possible to compile it into an executable file. This would improve performance, particularly when it's being called many times by PROTEUS.

This requires a "build" step to be implemented for SOCRATES, which is currently done manually.

See this page: https://julialang.github.io/PackageCompiler.jl/dev/apps.html

Currently, AGNI uses a grey surface albedo. However, it would be useful to instead use a spectral one. This can be easily provided to SOCRATES via atmos.bound.rho_alb, which has the shape (n_profile, n_basis_funcs, n_band).

More information on the SOCRATES side of things here: nichollsh/SOCRATES#5

The best approach for this is to store various surface albedo data and then have the user pick a particular surface material from the cfg file.

https://dspace.mit.edu/handle/1721.1/74201
https://sites.brown.edu/relab/relab-spectral-database/
https://pds-speclib.rsl.wustl.edu/search.aspx?catalog=RELAB