quickbackground for corner wavefront sensors not working for certain MJDs

Issue #54 resolved
Former user created an issue

When running phosim for stars located on corner wavefront sensors (starWfs.inst), with quickbackground (qckBkgnd.cmd), for certain MJDs in the instance file no donuts are made. I checked the same instance files changing the MJD, and it produces a star image for MJD 51591.093528, 59400, 59500, 59550, 59555 but doesn't for 59560, 59570, 59580. I attach the instance files, command file, and the sky_500.txt file for monochromatic SED (put in /data/sky). Interestingly, if quickbackground is changed to backgroundmode 0, the donuts appear even for the larger MJDs, which is why quickbackground is suspect . This behavior is present in both phosim_syseng4 branch aos, commit 8d22f3f , as well as the bitbucket master branch, v5.3.10, commit aa2ba60. We were hoping to use the quickbackground for Active Optics System simulations. Thank you!

Comments (8)

  1. John Peterson

    I tried a couple of these out, and I believe its just that some of these MJDs are rather close to sunset and there is just a lot of sky background there. So I don’t think its like the donuts are not there, its just that the background swamps them. So this would probably happen whether you used quickbackground or not. I would double check how you chose these MJDs and make sure are reasonably far from sunset. If you don’t think this makes sense, please let us know.

    [Also, I’m not sure at all about how this would work for syseng4 fork. That fork is probably about 3 years or 1000+ revisions old, so i don’t know if this is relevant back then. But its probably the same since you saw the effect there, but I am certainly not sure about that.]

  2. Krzysztof

    Thank you for a quick response. I am not sure if the hypothesis about being close to sunset time is correct, because the input observation times are all at midnight (apart from the earliest MJD tested that’s at 2:14 am). Below I list each obs time from instance file in MJD , and converted to ISO with astropy.time :

    Obs date [MJD] Obs date [ISO] Donut?
    51591.0935 2000-02-17 02:14:40.819 True
    59400.0000 2021-07-05 00:00:00.000 True
    59500.0000 2021-10-13 00:00:00.000 True
    59550.0000 2021-12-02 00:00:00.000 True
    59555.0000 2021-12-07 00:00:00.000 True
    59560.0000 2021-12-12 00:00:00.000 False
    59570.0000 2021-12-22 00:00:00.000 False
    59580.0000 2022-01-01 00:00:00.000 False

    In all cases the FITS header contains MJD-OBS which is exactly 7.5 seconds earlier than the MJD in the instance file, but I assume this is because the MJD-OBS keyword is the beginning time of each exposure, and MJD in the instance file the mid-point of each 15 second exposure. For all tests, AZIMUTH = 327.034005, ZENITH = 36.755732, AIRMASS= 1.248131.

    I checked the output fits files, and those that do not have donut do not show high background levels, which runs against the hypothesis of background swamping the donut. In fact, in all cases the background is at the level of approximately 1000 counts. I attach images of a single amplifier with trace, showing a case with donut image (mjd=59555) and without (mjd=59560). Could there be another reason for such phosim behavior?

  3. John Peterson

    Ok, good. A few things. I think you are mostly right about the MJDs and the background. It does look like there is potentially a little bit of twilight emission with these MJDs, but not enough to really add to the background significantly. One small correction though for what you said. When you quote midnight for most of the MJDs, those are for UTC time. In Chile, they will be 4 hours different, I believe, so something like 8 pm local, so that’s why twilight is slightly relevant but not exactly.

    But here is the problem. I get donuts and can’t reproduce the problem. For instance, I tried 51591 and 59580 below and see donuts in both, but you said the latter doesn’t have them. I used your catalog and command files as you have them, and I made two small changes:

    1. I set the exposure time to 0.15 seconds so it runs quickly
    2. I set “sunalt -90” so we don’t have any twilight issues

    Can you try running with the newest code and see if you get what I get? So get the newest code (v5.3.11) and pay attention to any error messages, and then I’m curious if you can get the same thing.

  4. Krzysztof

    Thank you for your answer! I tested two hypotheses: setting "sunalt -90" in the instance file, or shifting the instance file mjd (UTC) to correspond to Chilean (UTC-4) local midnight. First, with mjd=59560 (previously no donuts), adding "sunalt -90" to the instance file does produce donuts. Second, without "sunalt -90", but shifting the instance file mjd (UTC) by 4 hours forward, so that it's 4am UTC , or 12am UTC-4 (Chilean midnight): mjd=59560.166. This also produces donuts. So it seems that indeed the sunlight was the problem. I tested that in both v.5.3.11 as well as phosim_syseng4. Perhaps the other MJDs that were set to UTC midnight (Chilean 8pm, eg 59400 or 59555 above) happened to be far enough from the winter solstice (southern summer) so that sunlight was not that much of a problem. I tested that by shifting mjd=59580.0 (2022-01-01, Chile 8pm, no donuts) to mjd=59670.0 (2022-04-01, Chile 8pm), and the donuts appear. This seems to answer why the other instance files produced donuts despite being also at 8pm Chilean time.

  5. John Peterson

    Ok, good. I guess everything makes sense, except for one thing. If I allow the sunlight to be there and don’t set sunalt -90, however, I still get lots of background which I believe was why you couldn’t see the donuts before (and therefore there is no bug). But then that contradicts your tests that you just said two comments earlier. So I’m confused. Do you think those results were because of the old version? Or was something in those tests not the same as what you just did?

  6. John Peterson

    I think this is resolved. Will close this soon if preparation for v5.4. Please reopen if there are any other issues.

  7. Log in to comment