This causes the code to always warn that there are not terms evolving a given variable, rendering the warning useless.

An advanced ReMKiT1D example revisiting the advection problem has been written, but this time using the v1.2.0 UnaryTransform("shift") feature to define stencils without actually having to explicitly use stencil or matrix objects.

It will also showcase other v1.2.0 features including Grid helper functions.

The example in my dev branch works fine for CVODE and RK integrators but not for the BE integrator, which seems to cause a segmentation fault on the first iteration. Will need to investigate this in closer detail.

To do:

• Fix segmentation fault when using the BE integrator.
• Pass Jacobians and DualWidth into the divNode and pGrad functions - thereby making them grid-agnostic.

The models in common_models should have their documentation improved to make what they are doing clearer.

For example, it should be made clear that staggeredAdvection produces a central difference stencil on the staggered grid when advecting staggered variables.

One may not need to provide linCoeffs for an additiveDerivation however the assertion within the function definition prescribes this. A proposed change is to make a conditional statement so that if linCoeffs is provided that this assertion is checked but it is skipped if no linCoeffs are given.

At the moment, the RKWrapper assumes a linear workflow through the majority of the simulation construction process. For example, it does not store individual model objects, and instead adds their dictionary representation to its internal configuration state. This means that it is difficult or impossible to retrieve added models for potential removal, modification, or detailed reference.

Ideally, an improved design would store all of the objects necessary to build the configuration file in such a way that the individual components can be changed or removed without rebuilding the entire wrapper. This would likely require redesigning the majority of ReMKiT1D objects to enable their modification.

Given the breaking nature of this redesign, it is almost certain that a new wrapper class should be added instead of modifying the existing wrapper to enable the backwards compatibility with current linear workflows.

It is possible to add variables which do not have terms which are associated to them. This can lead to confusion and so a warning would be a useful addition

Previously, calculation trees and nodes have only been used to build the corresponding derivations for use in the Fortran codebase. However, examples have appeared where it would be preferable to have a function produce both a node/calculation tree for the Fortran code as well as something that could be evaluated in the Python environment.

As such, the following syntax is desirable.

a = Node("a")
b = Node("b")
c = a + sin(b)
c.evaluate(variables) # -> np.ndarray

where variables would be of type Dict[str,np.ndarray] and would contain the keys for the leafVariables a and b.

To support different custom UnaryTransformations that could exist in the Fortran code, the UnaryTransformation class should have an additional optional component of type Callable[[List[float], List[int], List[bool], np.ndarray], np.ndarray]. For basic functions, this should be provided by the calculation_tree_support module.

There are some instances where having the ability to describe how many degrees of freedom a certain temperature derivation has can be useful.

Currently, utilising the new DerivationTerm object requires the customDerivation associated with said DerivationTerm to exist in the wrapper already. It would be beneficial for this to be done as a one liner by having a function that adds the necessary customDerivation before then creating a DerivationTerm

The wrapper should be updated to support setting the timeloop.restart.resetTime JSON key.

Docstrings should be added to help explain plotting functionality.

There are missing docstrings in the Grid constructor and the addVar member function on the wrapper needs to have its documentation improved. Other improvements should also be done systematically.

I have made minor changes to the ReMKiT1D_limiters_CVODE.ipynb workshop to also include a model with no flux limiter, to demonstrate the nonphysical oscillations that result at the edges of the advecting box and why a limiter is necessary.

There are occasions where it is useful to have a number divided by a node. such as in the case of 1/Node. At present it is not possible for this to be done in the ReMKiT1D framework.

In common_models.py, function flowingIonEIColl, the argument "ionDensVar" needs to be an implicit variable, this should be mentioned in the documentation.

At the moment, there is no warning when users input a non-zero initial condition on the last (rightmost) cell boundary for variables on dual grids. This can lead to confusion, as it can confound with existing boundary conditions. For example, setting both a non-zero particle flux on the last cell as well as an explicit outflow boundary condition leads to those two fluxes adding together.

Given that there is a use case for setting these values to be non-zero (fixed outflow conditions), a warning should be added in case the user did not intend to do that.

At the moment it is possible to add a variable named x, which should not be allowed.

customFluid1DStencil should set all required variables to "none" when none are passed, as the Fortran code explicitly checks for "none" to determine whether there are variables required for a column of a stencil.

When many variables are derived, it is cumbersome to have to create a custom derivation for each derived variable. It would be simpler to pass the derivOptions to the variable as it is declared such that it can automatically add the custom derivation used in the variable's derivation rule.