Took Tess' RXTE light curve notebook idea from SciServer and wrote new version

[DavidT3]

HEASARC notebook review

Critical review criteria

The author of the pull request should make an effort to go through these check points and ensure that their submission satisfies each point - reviewers will also compare to these checklists.

Science review checklist

• Does using high-energy data make up a significant part of the tutorial?
• Is there a use case in the introduction that motivates the code?
• Does the code do what the introduction says it is going to do?
• Is it scientifically accurate?
• Have all necessary references to literature been included?

Formatting checklist

• Did you base your notebook on the HEASARC-tutorials template?
• Are all sections in the HEASARC-tutorial template included in your notebook?
• Is the notebook title compact and informative? It will be the name of the notebook on the HEASARC website!
• Have you populated the notebook front-matter (the metadata at the top of the notebook)?
• Is the kernel specified in the front-matter (e.g., heasoft, sas, ciao) correct for the notebook?
• Have you added an entry for your notebook in the *_index.md file for the containing directory?

Tech review checklist

• Documentation:
  • Is every function documented?
  • Do all code cells have corresponding narratives/comments?
  • Are all code comments of a purely technical nature? All narratives should be in Markdown cells.
  • Did you populate the 'Runtime' section?
• Notebook execution, error handling, etc.:
  • Does the notebook run end-to-end, out of the box?
  • Are errors handled appropriately, with try/except statements that are narrow in scope?
  • Have warnings been dealt with appropriately, preferably by updating the code to avoid them (i.e., not by simply silencing them)?
• Efficiency:
  • Is data accessed from the cloud where possible?
  • Is the code parallelized where possible?
  • If the notebook is intended to be scaled up, does it do that efficiently?
  • Is memory usage optimized where possible?
• Cleanup:
  • Have blocks of code that need to be re-used been turned into functions and placed in the 'global setup'-'function' section?
  • Has unused code been removed (e.g., unused functions and commented-out lines)?
  • Are comment lines wrapped so all fit within a max of 90 - 100 characters per line?
  • Do plots use color-blind friendly palettes for plotting? Try this simulator for a visual check.

[DavidT3]

Skipped the first doc build as I forgot that I need to release a new version of XGA with all the light curve additions.

[DavidT3]

@zoghbi-a @trjaffe - if either of you fancy giving this new notebook a review, that would be great (no worries if you're too busy though).

Clicking the 'All checks have passed' tab at the bottom of the PR page, and then clicking the 'check rendered docs here' link, and finally going to the RXTE light curve notebook page, will get you to the rendered version.

I may have lost focus on this one a bit, so fresh eyes would be great

[zoghbi-a]

This is a very valuable notebook, with lots of details. My high level comments:

• I think it is long. Maintaining this may be a challenge. It can probably be broken into 3 or 4 notebooks: 1- standard products from the archive, 2- extracting new products, 3- XGA's AggregateLightCurve and LightCurve (which are cool btw), and potentially. 4- the final analysis.
  3 is generic that can be useful for other missions too.

• On using XGA. Has the code been cross-verified? especially when it comes to the nuances of the fast timing light curves (e.g. GTI effects, barycentering, background etc). If we ask users to use it, we want to be sure it produces results that has been verified. Stingray is an option that has wider community support. I think it may be less of an issue if it is presented in a separate notebook as a 'community-software' section somewhere (similar to what we had for jdaviz and js9 etc).

• A general note. we should think more about the environment of the notebook. Do we need a conda yaml file? How do we handle multiple notebooks that may have conflicting dependencies.