Dark current in infrared unrealistic

[mb2448]

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.

[tdrobinson]

Hey Mike and Jake, I think there are two things going on here. One is the dark current rate. Mike points out that this seems low -- but maybe LUVOIR was/is assuming some improvements in that technology. The other is the number of lenslets contributing to the spectral bin in the different detectors. The visible detector is likely scoped to resolve the PSF at ~450 nm, and the number of contributing lenslets (and pixels) is growing as lambda**2. The sharp drop at 1 um occurs when we switch to the NIR detector, and the pixel sizes are now resolving the PSF at ~1 um. So, independent of the dark current rate, there is a big drop in the number of contributing pixels at 1 um. Mike -- I forgot to follow up after the Winter OWL. Like I said, I'm happy to Zoom to chat about the noise model or any project related stuff.

…

-Ty- -Ty-

On Thu, Jan 23, 2020 at 11:52 PM mb2448 ***@***.***> wrote: Hello, In running the script luvoir_demo.py demo, the dark current appears to precipitously drop off around 1 micron. [image: Figure_1] <https://user-images.githubusercontent.com/1314227/73049168-c1874f00-3e1f-11ea-9072-c78e64cde8a7.png> 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. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#6?email_source=notifications&email_token=AEDQWLD7TWSS7VLPYXOJMH3Q7KF2PA5CNFSM4KLBZX72YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4IIOD3PA>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEDQWLCK62UX7J6SLXDSI6TQ7KF2PANCNFSM4KLBZX7Q> .

-- Tyler D. Robinson, Ph.D. Assistant Professor Northern Arizona University

[jlustigy]

I second Ty's assessment here.

However, there is an extra subtlety in the code that I should mention and perhaps we can change the default behavior. By default (in luvoir_demo.py and in count_rates()) NIR = False for the purpose of setting the wavelength dependence of the dark current. But NIR = True for setting the size of the lenslets. So the behavior above appears to be only due to the drop in the number of contributing pixels at/beyond 1 µm, as Ty described. @tdrobinson, would you recommend any changes to this behavior?

Furthermore, I would caution that the telescope and instrument parameters in the luvoir_demo.py script are out-of-date relative to the LUVOIR Final Report. In my recent work with the LUVOIR team, I defined separate Telescope objects for each LUVOIR channel (UV, visible, NIR), each with their own nominal parameters. A similar procedure could be useful in this case.

[mb2448]

Thank you both for your input. I now see what you mean about the lenslet sampling. It is still surprising that the drop is so high, but I will dig further. This whole process has been quite educational. As a point of interest, it would be good to compare the BOL and EOL effects of detector performance. In my own experience testing the WFIRST EMCCDs one can get a factor of 10 difference in dark current from the effects of radiation damage. Very scary!

…

On Fri, Jan 24, 2020 at 8:41 AM Jacob Lustig-Yaeger < ***@***.***> wrote: I second Ty's assessment here. However, there is an extra subtlety in the code that I should mention and perhaps we can change the default behavior. By default <https://github.com/jlustigy/coronagraph/blob/master/coronagraph/count_rates.py#L527> (in luvoir_demo.py and in count_rates()) NIR = False for the purpose of setting the wavelength dependence of the dark current. But NIR = True for setting the size of the lenslets <https://github.com/jlustigy/coronagraph/blob/master/coronagraph/count_rates.py#L746>. So the behavior above appears to be only due to the drop in the number of contributing pixels at/beyond 1 µm, as Ty described. @tdrobinson <https://github.com/tdrobinson>, would you recommend any changes to this behavior? Furthermore, I would caution that the telescope and instrument parameters in the luvoir_demo.py script are out-of-date relative to the LUVOIR Final Report. In my recent work with the LUVOIR team, I defined separate Telescope objects for each LUVOIR channel (UV, visible, NIR), each with their own nominal parameters. A similar procedure could be useful in this case. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#6?email_source=notifications&email_token=AAKA3M5AELMXL2QBYKVQ7KTQ7MY4HA5CNFSM4KLBZX72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJ3WO3Q#issuecomment-578250606>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKA3M6XAIV7OAIYRIANNTTQ7MY4HANCNFSM4KLBZX7Q> .