Add a flag that will allow the root tracing algorithm to use an extrapolation method to guess the next frequency value, rather than simply using the previous frequency value.

Add nice formatting such as headers, lists, code snippets. Consult the guide for syntax.

Use the same bessel function routine for NHDS and ALPS core portion of code.

Add a functionality to allow for orthogonal polynomials to be used for the analytic continuation, rather than the prescribed fit functions.
This is to be done with a general linear least squares method, and it currently being tested in the polynomial_v00 branch of the code.

The log-fitting takes the log of f0, but then it fits the normal functions to it. The problem happens in ALPS_analyt.f90 in the function determine_JT. The derivatives of the function with respect to the fit parameters must be taken of the log of the function if logfit is set to TRUE.

Move all tests into a dedicated tests/ directory, adjust the yaml test routines accordingly

Simulation outputs in distributions and solutions should be ignored

• Compare Heating Rates to PLUME, NHDS
• Add and verify density eigenfunction calculation.

At the moment, the LM fitting routine for the analytic continuation is free to find any values for the fit parameters. If possible, we should allow the user to set a boundary on the fit parameters. For instance, they may want to choose that only positive density values are permitted. With positive density values only, the logfit would not return NaN when applied during the fit evaluation.

Currently my understanding is the tests run but no check is made, other than the executable exited with status 0 (ie. didn't crash). We should add some checks on the correctness of the results. You could rewrite the tests using an unit testing framework (pFunit is a popular framework), but setting it up can be a bit heavy. An easier option is to store reference output files and when the tests run, compare values from the output to those in the reference. The comparison script can be written in any language, as an example I've set up a testsuite with a shell script to run tests and a python script to check correctness in a different Fortran project.

Write a mark down file that explains the basic steps to run ALPS.

I suggest adding the topic plasma-physics in the About section, as explained at https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/classifying-your-repository-with-topics

At high kperp, the dispersion relation sometimes exhibits jumps in the frequency and growth rate solutions. A change to positions_principal and n_resonance_interval does not mitigate this significantly.

If these jumps occur, they usually occur at the same kperp, independently of kpar. This suggests that they are related to the Bessel function routine at high kperp.

This problem primarily occurs when the code calculates high-frequency electron waves. It especially occurs also when working in electron mode for these solutions.

Set up website and folder structure for code documentation.

Look for routines that we actually don’t use anywhere anymore (like old secant method) and remove when necessary. Also remove the use_secant flag in all input files.
Check any licensing issues with code from external sources.

Parameters to be verified:

• zero net current
• quasi-neutrality
• ...

Under some conditions, the new domegadk feature, which extrapolates the new initial guess based on the previous solution in of the dispersion relation, diverges. The code then loses a given mode and presents a diverging solution for which the frequency goes to +/- infinity until the code crashes.

We should include a safeguard to check that the derivative domegadk does not lead to such a diverging solution.

We could also add a user command that allows to turn the feature on or off as needed. In some examples, the code works much better with this feature, especially when crossing through gamma=0.

The feature has been disabled for now.