ericagol / celerite.jl Goto Github PK

• Update the Julia tutorials for celerite.jl, making examples similar to the Python notebooks created by @dfm . There is a Julia notebook; make sure it is compatible with cholesky version. @giordano

When J > 4, should be faster to use LAPACK solver. There are the gbtrf & gbtrs functions that are built into Julia, but also the MKS solver that may require recompiling Julia.

Once L^{-1} y is computed, simply dot with itself, dividing each term by D_n.

Update A_{n,n} & \tilde V_{n,j} in place, and use these to represent \tilde W_{n,j} and D_{n,n}.

When I add, commit & push changes to celerite.jl, the package doesn't seem to update these changes.

Make benchmark plots of speed vs. size of problem in celerite comparing pure Julia vs. Python versions.

The prediction is rubbish - this needs to be investigated and fixed.

I am putting some effort to develop a package for high-performance geostatistics in Julia. One of the main algorithms is Kriging estimation, which is nothing more than a n-dimensional GP with a general distance metric: http://juliohm.github.io/GeoStats.jl/stable/estimation.html

If you feel that users of celerite.jl would benefit from GeoStats.jl in the n-dimensional case, it would be great to add a reference to it in the README 😊

Feel free to close the issue anytime, thanks for porting the celerite project to Julia.

• Add capability to freeze and thaw parameters, as well as other features available in Python version created by @dfm @giordano

• Add in multiplication so that one can filter data.

• Add in scaling tests in an iJulia notebook. Check that scales as J^2.

• Create tests for Julia version of celerite, following Python examples by @dfm @giordano

The log likelihood seems to blow up when called multiple times.

Some new routines have been added which implement the Cholesky solver in Julia:

gp.jl: This contains the subroutines and basic functionality - now includes simulation & prediction.

sturms_theorem.jl: Uses Sturm's theorem to check that kernel is positive definite.

Problem: These routines are written with K = L L^T, rather than K = L D L^T, which is how the C++/Python versions were implemented. These should be made consistent.

• Rewrite as LDLT

• Convert code to same format to be compatible with extended matrix formalism.

• Figure out how to update celerite.jl package.

• Finish developing cholesky branch, and merge with master branch.

See if we can implement LBFGS-B.

1). Change compile matrix to include alpha_imag
2). Change notation of solver to match that in the paper. Get rid of 2^N in determinant.
3). Create a type (analogous to gp object) that stores the matrices/vectors to prevent the need for reallocation of memory.
4). Add different kernel types, and add capability of freezing/thawing parameters.
5). Add examples that are similar to Dan's rotation & asteroeseismic examples.

If there are no real terms, then J0=0. Right now this is not working in the current version of the code.

The documentation of how to use the Julia version is out of date:

http://celerite.readthedocs.io/en/stable/tutorials/julia-first/

In particular, the predict code is not working, throwing an error of the mismatch between the length of the array given to apply_inverse.

Also, the _ldlt versions need to be merged.

Also threw an error on line 272 of gp.jl:

    Dn = sqrt(diag[n]+a_sum-2.0*Dn)

due to negative value in square root.