juliaastro / lombscargle.jl Goto Github PK

I am currently implementing a time series surrogate algorithm based on the lombscargle periodogram JuliaDynamics/TimeseriesSurrogates.jl#67.
There I need to compute the lombscargle periodogram for shuffled versions of the same signal with the same times vector a few thousand times.
I benchmarked my implementation and most of the time is spent in the computation of the lombscargle periodogram.

Is there a way to reuse the Lombscargle PeriodogramPlan for this so that I could update the signal of the PeriodogramPlan?

I have seen the bootstrap methods in this package, but I don't understand, why this shuffles the times vector, but from that I would assume, that something similar for the signal might be feasible.

I think that this repo may benefit from adding CompatHelper. For example SpecialFunctions is now at v.0.10.0 and the compat bounds must be updated.

I can make a PR if you want.

Hello there,

My name is Gabriel i wanna ask something here.

I'm using lombscargle periodogram to verify some frequencys in my orbits dynamics. I'm starting with a simple example a mean motion resonance 1:1.

In this case i'm getting what i want (1 period of peak). However if i follow the best fit frequency model described in the docs i have the result below.

I'm not sure if the fitting model is working very well for my model, there is something i could be doing wrong ? I would love some tips to help me understand this tool.

Hello
Does this algorithm implement the generalised Lomb-Scargle periodogram as described in The generalised Lomb-Scargle periodogram - A new formalism for the floating-mean and Keplerian periodograms,
M. Zechmeister and M. Kürster ? ( pdf here )
If not, do you please have any plan to integrate it ?
Thanks

Multi-threading may speed-up computation of periodograms.

Currently, this feature is tagged as experimental in Julia 0.5. I started working on this feature in multi-threading branch, adding support only multi-threading support only where it doesn't degrade performance (mainly for computation of bootstrap dataset).

This issue is used to trigger TagBot; feel free to unsubscribe.

If you haven't already, you should update your TagBot.yml to include issue comment triggers.
Please see this post on Discourse for instructions and more details.

If you'd like for me to do this for you, comment TagBot fix on this issue.
I'll open a PR within a few hours, please be patient!

Press-Rybicki functions in press-rybicki.jl are slower than necessary because of JuliaLang/julia#28126. See also https://discourse.julialang.org/t/large-performance-regression-of-vectorized-functions-on-master/12657. This ticket is just to track the issue, I don't think we need to do anything on our side.

The README contains a link to https://lombscarglejl.readthedocs.io/en/latest/#planning-the-periodogram, but that shows the RTD default index rather than the root manual page. https://lombscarglejl.readthedocs.io/en/v0.0.2/ is fine.

After comparing with [ZK09] and the Astropy documentation, I believe the normalization between PSD and standard has a typo in the documentation and should be:

   P(f) = p(f) * W * YY / 2

(i.e., there is currently a W missing). Astropy documentation lists the unnormalized psd to be

   P_psd(f) = 0.5* (Chi^2_ref - Chi^2(f)

whereas [ZK09] writes

   P_standard(f) = (Chi^2_ref - Chi^2(f)) / (Chi^2_ref)

So to transform between the two, you must multiply by Chi^2_ref/2, and [ZK09] gives Chi^2_ref as W * YY

After testing a few datasets, including a W term does indeed produce identical periodograms.

It would be interesting to implement the method described in

• Leroy, B. "Fast calculation of the Lomb-Scargle periodogram using nonequispaced fast Fourier transforms", A&A, 545, September 2012, A50, https://doi.org/10.1051/0004-6361/201219076

For the NFFT, there are

• the NFFT.jl package, a pure Julia implementation of the Non-equidistant Fast Fourier Transform
• the Julia interface to the C library, which however is not packaged properly and thus is not easily callable by this package.