Really nice work! Is the documentation going to be completed?

[yangcht]

It seems that the current documentation is incomplete (404 errors from the link in the main readme).

[autocorr]

Hi! Thank you, and thanks for pointing that out, the actual documentation uses Documenter.jl and is located at https://autocorr.github.io/Jadex.jl/dev/ from the little "docs" badge, not on ReadTheDocs. Looks like I left that in from when I assumed I'd be using ReadTheDocs (it is simpler to execute Julia code on the build server using GitHub actions and that's what the tutorial on Documenter.jl uses).

The documentation is not especially thorough. If you don't need the highest performance, then following the "Quickstart guide" should be sufficient: results are returned in a DataFrame. But if you're planning on using it for MCMC (judging by your other work!), you'll want to use in-place operations on the solution to avoid allocations and garbage collection, e.g.:

using Jadex
mol = Specie("hco+@xpol", datadir="path/to/LAMDA/files")
rdf = RunDef(mol, density=Dict("h2" => 1e4), tkin=20.0, cdmol=1e13, deltav=1.0)
sol = Solution(rdf)
solve!(sol, rdf)

# One can get excitation temperature and optical depth directly from the solution:
my_tau = sol.τl[3]  # HCO+ 3-2
my_tex = sol.tex[3]

# If one needs the radiation temperature and integrated intensities, then optionally run
# `get_results` and a `DataFrame` is allocated:
df = get_results(sol, rdf)

# Reset the solution and fill it with zeros so it can be re-used with new `rdf` when
# calling `solve!(sol, rdf)`.
reset!(sol)

If you make a representative RunDef to initialize the Solution with, it can be used in-place in succeeding operations. It makes multi-threaded, multi-chain MCMC runs more complex though as in-place operations won't be thread-safe (one would need an array of sol instances indexed by the thread-ID, or to use process based parallelism that copies all objects at the start).

Note that the run definition RunDef allocates a little bit, so this does add some garbage collection overhead, but I've noticed the GC clean-up didn't add much overhead in this use-case. The multi-threaded grid computation would benefit from in-place operations on the RunDef however, since all threads share the same GC and clean-up calls are thread locking.

Clear skies,
Brian