-
Notifications
You must be signed in to change notification settings - Fork 168
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
Modify mosrange to Not Abort on Bad Images #3606
Comments
Why this is importantIf working with the current version of mosrange, weeding out bad images requires iteratively running the application. This can be a time consuming and tedious process when working with large volumes of data. By allowing mosrange to do as much as possible, you can run mosrange once then remove and/or check all of the bad images in a single pass. It is also easier and more robust to automate removal of bad images via an output list instead of having to parse exception messages. |
I am a bot that cleans up old issues that do not have activity. This issue has not received feedback in the last six months. I am going to add the I will post again in five months with another reminder and will close this issue on it's birthday unless it has |
This is still outstanding |
Thank you for your contribution! Unfortunately, this issue hasn't received much attention lately, so it is labeled as 'stale.' If no additional action is taken, this issue will be automatically closed in 180 days. |
Reopened by request |
Closed via #5292 |
Description
Occasionally, mosrange would fail on one or more images which aborts the application. We altered mosrange to trap failing calculations for each image, log the image and remove it from the list. mosrange continues to completion processing as many image cubes as possible.
We found that this issue could occur rather frequently and randomly due to issues with SPICE data and shape models. Producing lists of failing images allows one to investigate the underlying issues.
Three new parameters were added: ERRORLOG, ERRRORLIST and ONERROR.
ERRORLOG allows the user to provide the name of a file where the error is reported.
ERRORLIST allows the user to provide the name of a file where the name of failed images are written.
ONERROR can be used by the user to choose how these file errors are handled when they occur. ONERROR=FAIL preserves pre-existing behavior and will result in a program error.
Example
The text was updated successfully, but these errors were encountered: