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

Fixing tests related to image solving with simulator #627

Merged
merged 2 commits into from
Sep 26, 2018

Conversation

wtgee
Copy link
Member

@wtgee wtgee commented Sep 23, 2018

  • Use unsolved image so we can test solving
  • Pass skip_solved=False during analyze_recent. Helps with testing when
    the same image is used repeatedly, shouldn't affect normal usage.
  • Add some extra logging
  • Misc cleanup

* Use unsolved image so we can test solving
* Pass `skip_solved=False` during `analyze_recent`. Helps with testing when
the same image is used repeatedly, shouldn't affect normal usage.
* Add some extra logging
@codecov
Copy link

codecov bot commented Sep 23, 2018

Codecov Report

Merging #627 into develop will decrease coverage by 0.02%.
The diff coverage is 58.33%.

Impacted file tree graph

@@             Coverage Diff             @@
##           develop     #627      +/-   ##
===========================================
- Coverage    67.22%   67.19%   -0.03%     
===========================================
  Files           65       65              
  Lines         5690     5692       +2     
  Branches       798      798              
===========================================
  Hits          3825     3825              
- Misses        1655     1656       +1     
- Partials       210      211       +1
Impacted Files Coverage Δ
pocs/camera/simulator.py 100% <100%> (ø) ⬆️
pocs/scheduler/dispatch.py 98.03% <100%> (ø) ⬆️
pocs/observatory.py 76.1% <28.57%> (-0.46%) ⬇️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 2f6f5fb...aa15829. Read the comment docs.

@wtgee wtgee requested a review from jamessynge September 23, 2018 23:26
@wtgee wtgee mentioned this pull request Sep 23, 2018
@wtgee wtgee changed the title Fixing tests Fixing tests related to image solving with simulator Sep 25, 2018
@wtgee wtgee requested a review from AnthonyHorton September 26, 2018 06:58
Copy link
Collaborator

@AnthonyHorton AnthonyHorton left a comment

Choose a reason for hiding this comment

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

Code changes look fine to me, so if it's solving the problem it was intended to solve LGTM.

@AnthonyHorton
Copy link
Collaborator

An aside on the image solving, we noticed during the recent testing with Huntsman that if given ludicrously large images the solving will timeout. We saw this consistently when one of the 50 Mpixel FLI ML50100 cameras was enabled, which due to its name would become the default primary imager. We got a warning in the log about analysis failing due to solving timing out for every image we took.

@wtgee
Copy link
Member Author

wtgee commented Sep 26, 2018

An aside on the image solving, we noticed during the recent testing with Huntsman that if given ludicrously large images the solving will timeout. We saw this consistently when one of the 50 Mpixel FLI ML50100 cameras was enabled, which due to its name would become the default primary imager. We got a warning in the log about analysis failing due to solving timing out for every image we took.

There is a timeout param than can be passed through get_solve_field that will let it keep going. I use that on the Pi where the solve can take 45-60 seconds. Default is 30.

But we should probably figure out if the solving can be done asynchronously (and/or if needed at all for Huntsman observing).

@wtgee wtgee merged commit 92e7f2c into panoptes:develop Sep 26, 2018
@wtgee wtgee deleted the test-fixes branch September 26, 2018 09:51
@AnthonyHorton
Copy link
Collaborator

There is a timeout param than can be passed through get_solve_field that will let it keep going. I use that on the Pi where the solve can take 45-60 seconds. Default is 30.

I suspected that there was a parameter for this somewhere.

But we should probably figure out if the solving can be done asynchronously (and/or if needed at all for Huntsman observing).

Definitely. The processing that goes on at the end of each science exposure can take quite a while. It's not a huge issue for 5+ minute long galaxy exposures but it is contributing to some substantial gaps in temporal coverage when trying bright star transits. Should look at deferring as much as possible to after the next exposure has started.

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.

2 participants