jlustigy / coronagraph Goto Github PK

Create an example notebook in the docs that compares coronagraph with EXOSIMS (https://github.com/dsavransky/EXOSIMS) where the two codes have overlapping functionality.

Ground-based noise modeling was introduced for simulating future 30-m class coronagraph spectra in Meadows et al. (2018). There are numerous improvements that can be made to generalize this functionality (telescope location, target airmass, etc.) using direct calls to the ESO SKYCALC tool.

I'm creating this issue because your repo contains a conf.py file with

nbsphinx_prompt_width = 0

... presumably in an attempt to remove the prompts from code cells.

I just want to give you a heads-up that this will stop working once spatialaudio/nbsphinx#439 is merged.

For more reliable alternatives, see https://nbsphinx.readthedocs.io/en/latest/custom-css.html.

Hello,

In running the script luvoir_demo.py demo, the dark current appears to precipitously drop off around 1 micron.

This is the opposite behavior of what one would expect. Dark current for infrared detectors is far higher than for optical, for equal pixel sizes. Why does this occur? The culprit appears to be this set of lines in the function set_dark_current

    if NIR:
        iNIR  = (lam > 1.0)
        # Set dark current based on NIR detector properties
        if ( lammax <= 2.0 ): De[iNIR] = De_nir * np.power(10., (Tdet-120.)*7./100. )
        if ( lammax > 2.0 ) and ( lammax <= 4.0 ): De[iNIR] = De_nir * np.power(10., (Tdet-80.)*9./140. )
        if ( lammax > 4.0 ) and ( lammax <= 7.0 ): De[iNIR] = De_nir * np.power(10., (Tdet-40.)*11./140. )
        if ( lammax > 7.0 ): De[iNIR] = De_nir * np.power(10., (Tdet-30.)*11./70. )
        # Don't let dark current fall below a threshold
        iDe = (De[iNIR] < De_nir)
        De[iNIR][iDe] = De_nir

    return De

where the default value for De_nir is 0.001 e/pix/s. This appears to be a typo, as this does not look correct. Dark current rates for H2RGs are about 0.01 e/pix/s (see Figure 1 [here] (https://iopscience.iop.org/article/10.1086/661663)) and for SAPHIRA LmAPDs it is about a half of this in some published data.

Hi, Jacob!

Thank you so much for putting all this in to Python and documenting it so well!

I had just one issue that I'm running into where when using CoronagraphNoise even if I adjust the wantsnr value and run run_count_rates, that DtSNR doesn't ever change. I think it's just always using the default wantsnr=10 value. Do you have an idea of why this could be happening?

Best,
Thea

Very cool project!
In the example "Degrading a spectrum" from the docs, the last Figure shows some jitter. Sometimes, higher resolution results in lower albedo. I understand that this comes from the grid placement, as can be seen in the second-to-last Figure.

• If the grid placement can be chosen in advance, it can be optimized on a (one?) certain wavelength. Then, one could test the optimal placement.
• If the grid placement is not optimized, it would be more useful to show the average albedo. This could be done by iterating over a grid (or random set) of placements.

In both cases, the last Figure would be downward sloping.