v0.6

[fmeirinhos]

There are a couple of key goals for this version:

- [ ] Reformulate the VCABM functions to operate in-place in the Green functions (see branch v0.5 ideas)
- [ ] Remove the dependency on RecursiveArrayTools

• Have GreenFunction be a subtype of AbstractArray and ultimately create the appropriate broadcasting rules (namely copy!)
• Update the test suite
• Remove the notebooks from the repo (will later be reinstated but this will help us achieve 100% Julia purity)

[fmeirinhos]

Would it make sense to completely get rid of GreenFunction objects and substitute them for, e.g., SkewHermitian data structures (for Greater / Lesser) or Symmetric data structures (for Classical)?
These data structures would be what implements the "special indexing" or, if wanted, optimised data storage (see current SkewHermitianArray).

That would mean that then a GreenFunction would be a "higher-order" object, that uses these data structures to access correctly the data but then could also have more traits such as the underlying time-grid, quantum number information, etc.

[fmeirinhos]

It's very strange that the solver doesn't achieve the precision levels we want ever for a very simple "integrable" model.
extend_cache must be reviewed (for the millionth time).

Also: why manually running the tests works but through the package manager it throws some weird errors?

[fmeirinhos]

It's very strange that the solver doesn't achieve the precision levels we want ever for a very simple "integrable" model.
extend_cache must be reviewed (for the millionth time).

Also: why manually running the tests works but through the package manager it throws some weird errors?

It appears the problem was in the test suite 😄

[fmeirinhos]

To be able to remove both the dependancy on RecursiveArrayTools and do VCABM in-place, we would need to use an unzip function (possibly on Julia 1.7 - JuliaLang/julia#33515) or completely change the way the user supplies the vector functions f_vert and f_diag. The latter is undesirable since the current f_vert and f_diag are what makes sense from a mathematical POV.

Given that the solver is essentially a 1-time ODE stepper that each step calculates
rhs := [f_vert(t_1, t_N); f_vert(t_2, t_N); ...; f_vert(t_N, t_N); f_diag(t_N, t_N)]

unzip would basically allows us to work with the transpose of this nested-array
rhs := [[f_vert(t_1, t_N)[1], f_vert(t_2, t_N)[1], ...], [f_vert(t_1, t_N)[2], f_vert(t_2, t_N)[2], ...], ...]

This rhs form is what needed to operate in-place
u[1](t_N + dt) = u[1](t_N) + dt * rhs[1]
u[2](t_N + dt) = u[2](t_N) + dt * rhs[2]
...

This hopefully would make the solver even more general (notation-wise) but, who knows, possibly even faster due to more in-place operations.