Milestone: periodogram

[fjebaker]

The current implementations of some of the lightcurve and Fourier methods are a little cumbersome, and rely on idioms that are not necessarily ideal in Julia (e.g. having multiple different return types in if branches, using runtime strings to dispatch different methods). The idea then is, as part of working towards the goal of reproducing the exploratory Python tutorial , to update these implementations with small building blocks from which we'll later compose the complex program. The interfaces should be simple, do one thing and do that thing well.

To make a periodogram we need to be able to

• Read in eventlist files (Reading events files #27)
• Convert the eventlist to a lightcurve (Converting events to lightcurves #28)
• Visualise the lightcurve for inspection (Plot recipes for lightcurves #29)
• Compute the spectra via Fourier transformation (Fourier transforms and spectra #33)
• Compute the periodogram via Bartlett's method

Paraphrasing Matteo's words: the Bartlett periodogram can be computed either from the eventlist or from the lightcurve. When computed from an eventlist, there are two ways that we can normalise it, either segment-by-segment or after averaging. The results are not the same as the mean count rate changes between segments.

This issue will track progress towards reproducing the Periodogram tutorial from the Python documentation.
I will update this issue description as we progress, and open smaller issues for tasks that need to be completed along the way.

Feel free to start discussion in the comments of this issue if you have alternative suggestions or identify something new that needs doing as part of implementing periodograms :)

My suggestion is to keep the existing fourier.jl file as it is but deprecated, and use the implementations as reference for implementing our new methods. This should hopefully save time, as most of the hard work has already been done, and we are principally modifying the interfaces. We can then reuse the existing test cases as well.

---

Tagging @kashish2210 and @JawadAhmadCS

[fjebaker]

I should also mention, to avoid overlap, if you are planning to work on an issue, please announce it and I'd recommend not to start working on it until you are assigned to avoid duplicating eachother's work.

I'm also going to start asking you to review eachother's PRs too :)

[kashish2210]

This looks good
@fjebaker I am planning to work on this

[kashish2210]

I have previously studied this using Stingray in Python and perform tests using nicer data
at time was getting error in making this :

my error was that I was getting box not aligned for a zooming blue areas

for codbase I have uploaded my notebook

[fjebaker]

Hi @kashish2210 are you happy to work on #27 then? I will assign this to you if so :)

[JawadAhmadCS]

Thanks for mentioning me! @fjebaker I'm also interested in working on this, but since @kashish2210 has already taken it up, I'll let them proceed first to avoid duplication. In the meantime, I'll work on other issues. If needed, I can step in later if any improvements or refinements are required.

[kashish2210]

Hi @kashish2210 are you happy to work on #27 then? I will assign this to you if so :)

Yup :)

[fjebaker]

@JawadAhmadCS I will assign you to #28 which you can already start working on but will rely on #27. Provided @kashish2210 you can let us know what the eventlist struct will look like, that will allow you to start prototyping the code

[JawadAhmadCS]

Thanks, @fjebaker! for assigning me #28. I'll start working on the initial implementation and structuring the LightCurve, but I’ll wait for @kashish2210 to define the eventlist structure before finalizing the approach.

[kashish2210]

I am going to use this struct

struct DictMetadata
    headers::Vector{Dict{String,Any}}
end
struct EventList{T}
    filename::String
    times::Vector{T}
    energies::Vector{T}
    metadata::DictMetadata
end

you can refer to this for #28

I have finalized it :)

[fjebaker]

I replied about the design of the event list in #27 :)

[JawadAhmadCS]

Hey @kashish2210, we need to finalize a single struct for EventList and stick to it while working. Even if the initial struct wasn’t finalized, that doesn’t mean it should keep changing every few hours. The right approach is to first define one struct properly and work on it while you focus on reading events, I’ll simultaneously work on converting them into a lightcurve.

Once both parts (event list and lightcurve conversion) are complete, we can modify the struct. But if the struct keeps changing independently, it will make development inefficient.

I am going to use this struct

struct Meta
    headers::Vector{Dict{String,Any}}
end
struct EventList{T}
    filename::String
    times::Vector{T}
    energies::Vector{T}
    metadata::Meta
end

you can refer to this for #28

Note

this is not finalized we may include or exclude some of the defines :)

Hey @kashish2210, we need to finalize a single struct for EventList and stick to it while working. Even if the initial struct wasn’t finalized, that doesn’t mean it should keep changing every few hours. The right approach is to first define one struct properly and work on it while you focus on reading events, I’ll simultaneously work on converting them into a lightcurve.

Once both parts (event list and lightcurve conversion) are complete, we can modify the struct. But if the struct keeps changing independently, it will make development inefficient.

[kashish2210]

Sorry I didn't remove the note I have finalized the structure u can take example of PR. #30

[JawadAhmadCS]

I had been working on the implementation based on the initial EventList struct provided earlier. I spent the whole night working on it, but due to exhaustion, I fell asleep before submitting it. Now that I woke up and was about to submit, I noticed the struct has been modified. Because of this, I now need to update my implementation accordingly.