Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update unit tests for the new code installed via setup.py #259

Merged
merged 31 commits into from
Nov 23, 2021

Conversation

rmjarvis
Copy link
Contributor

@rmjarvis rmjarvis commented Nov 5, 2021

This updates some of the unit tests to work with the new code structure. Specifically, the following files now all work with imsim installed with setup.py:

test_FWHMgeom.py
test_atmPSF.py
test_batoid_wcs.py (already was working prior to this PR)
test_cosmic_rays.py
test_fopen.py
test_instcat_parser.py
test_logging.py
test_optical_zernikes.py
test_psf.py
test_tree_rings.py
test_trimmer.py

I've marked some places of concern with XXX comments. The most notable of these, I think, is about the WCS in test_instcat_parser.py. The Batoid WCS for the test instance catalog seems to be about 10 arcsec off. (Not uniformly, but that's ~ the maximum error.) That seems like more than we should have expected, so maybe @jmeyers314 could take a look at this to see if this is expected because you are doing something right now that used to be wrong, or if there is something here to be fixed.

There are more test files still to convert over, but this seems like enough of a start that it's worth people looking over the updates so far.

@rmjarvis rmjarvis changed the title Setup py tests Update unit tests for the new code installed via setup.py Nov 7, 2021
@rmjarvis
Copy link
Contributor Author

Update: I rebased onto main to use Jim's new camera code.
Also, I managed to get github actions working with stackvana (installed with mamba), running the tests that are working so far, and the CI agrees that they are all working. :)

@cwwalter
Copy link
Member

Awesome!

Copy link
Collaborator

@jchiang87 jchiang87 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added comments at most of your XXX questions, but didn't go through the changes in detail otherwise. I'll have a closer look, but wanted to address those questions right away.

imsim/util.py Outdated
import logging
import sys

# XXX: unneeded?
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I don't think we need this any longer.


# XXX: I think this is probably not needed anymore. Now use GalSim logger.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, agreed.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good. Removed this. Also test_TracebackDecorator and test_config_reader.


Returns:
the constructed WCS object (a galsim.GSFitsWCS instance)
"""

# If a string, convert it to astropy.time.Time.
# XXX Assumption is that string time is in scale 'TAI'. Should make sure
# to make this consistent with OpSim.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

imsim/instcat.py Outdated
# Check for some reasons to skip this object.
# XXX: Is this right? We require dust?
# The previous code had that galactic_av = galactic_rv = 0 is invalid.
# That doesn't seem right to me...
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the problem with Rv=0 using the lsst_sims code (and also for rubin_sim) is that there would be a divide by zero encountered (even if Av=0) at this line.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But if no dust is given in the input, can't we just not apply any extinction from dust? I.e. Av=0, Rv=1.

Copy link
Collaborator

@jchiang87 jchiang87 Nov 19, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sure. I'm not advocating we keep things as they are. I was just giving the reason why I think the code is written this way. Same applies to my other comments.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We ran into this before:

#213

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I changed this so these are not skipped, but are treated as Av=0, Rv=1.

chunk_size=chunk_size)
self.assertEqual(len(objs[sensor]), 24)
# XXX: We don't use chunking anymore. If we revisit this and put it back in,
# then we can re-enable this test.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok with me, though I wouldn't think we'd be using the InstCatTrimmer at all anymore.

Copy link
Contributor Author

@rmjarvis rmjarvis Nov 19, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right. I meant if we decided that the new code should be chunking like you did in the trimmer, then we might want a version of this test, modified to test the new code. I guess I'm also kind of prodding that we recall why we did chunking in the old code and think about whether it would make sense to add something similar now.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IIRC, the original reason was to avoid using up a lot of memory when reading in the instance catalogs (which covered the full focal plane) since most of the entries would be omitted once the objects that landed on the CCD were identified.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, I've removed this. In the new code, we already have the WCS as we're reading in the file, so there's no overhead of keeping any objects in memory that won't end up being kept.


ra_arr = np.array([pos.ra.rad for cat in all_cats.values() for pos in cat.world_pos])
dec_arr = np.array([pos.dec.rad for cat in all_cats.values() for pos in cat.world_pos])
# XXX: These are only within 1.e-4 radians, which is kind of a lot.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Almost all of the tests in this file were written by Scott, so I think we should just update things in a way that makes sense to us.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm hoping @jmeyers314 can take a look at this test to see whether the previous version did make sense, and the failures are a sign of a bug or if the test isn't quite relevant anymore given the new wcs handling.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll take a closer look. Browsing main, it looks like these positions weren't previously tested at all? Is that right? (So maybe they were always 1e-4 rad off?)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

They weren't tested on main (since we weren't running these tests), but I'm pretty sure they were tested in v1.0. That was with the older wcs code, not the BatoidWCS.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that is right, it used the sims code with the distortion model from for the WCS as we discussed before.

for i in range(cat.nobjects):
obj = cat.getObj(i, bandpass=bp)
if 0:
# XXX: The old test used the sims Sed class. Circumventing this now,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok, with me.

self.assertGreater(valid, 10)
self.assertGreater(len(valid_chip_names), 5)
if 0:
# XXX: This doesn't seem relevant anymore. But leaving this here in case we want
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok.

if len(i_obj) == 0: continue
i_obj = i_obj[0]
if 0:
# XXX: The old test using the sims Sed class.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok.


self.assertEqual(meta['gain'], 1)
self.assertEqual(meta['band'], 'r')
# XXX: These used to be nexp=2 ?? and exptime=15. I guess per snap, but we're not doing
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok, with me.

Copy link
Collaborator

@jchiang87 jchiang87 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Except for the one comment about removing 'Latiss' as a camera option, looks good to me.

imsim/camera.py Outdated
"""
Return an lsst camera object.

Parameters
----------
camera : str
The class name of the LSST camera object. Valid names
are 'LsstCam', 'LsstComCam', 'Latiss'.
are 'LsstCam', 'LsstComCam', 'Latiss'. [default: 'LsstCam']
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking at the check for telescope above,

if telescope != 'LSST':
    raise NotImplementedError("Batoid WCS only valid for telescope='LSST' currently")

it occurs to me that we should omit 'Latiss' from the camera options here and below.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK. I don't actually know what Latiss is. I guess that's AuxTel maybe?
I'm fine with removing that for now, but I guess people may want to make simulations of that eventually. So we should add an issue to add that back in.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, nvm I guess. That's a slitless spectrograph. Yeah, we're never going to simulate that with ImSim (at least until GalSim Issue #1018 is done). So just removing this is probably right.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right: LSST Atmospheric Transmission Imager and Slitless Spectrograph (LATISS) on the Auxtel.

For the future I wonder if the way to do something like this would be to have dispersive elements in Batoid?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree we don't need to worry about LATISS now, but Batoid does have the relevant model here. The grating is removable, so it's possible to observe and simulate in imaging mode. I know roughly how to insert a dispersive element in batoid as basically a phase screen, but haven't thought through all the details yet. In particular, some kind of ray splitting must be required for different orders and some kind of throughput vs wavelength/order function must be required or emerge too.

@rmjarvis
Copy link
Contributor Author

I opened Issue #262 for addressing the WCS regression tolerance being a bit large. I think everything else has been resolved, so this can probably be merged, but @cwwalter if you want more time to look it over, just say so.

@cwwalter
Copy link
Member

OK, LGTM and we will track #262 separately.

@rmjarvis rmjarvis merged commit 3f304bd into main Nov 23, 2021
@rmjarvis rmjarvis deleted the setup_py_tests branch November 23, 2021 18:25
@rmjarvis rmjarvis restored the setup_py_tests branch November 23, 2021 18:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants