unhandled exception in make_polarimetry_groups due to wrong data #63
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
can the data be fixed at raw level? |
It seems that all time related fields in the header are wrong, e.g: https://vhega.iaa.es/iop4/admin/iop4api/rawfit/details/140815 So I would say no. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We have found that in some cases several files in an epoch have the same juliandate. This should not happen (it is a problem with the data), but when it does, it causes an exception in make_polarimetry_groups.
For the case of making the polarimetry groups, a workaround can be to sort by filename too, to make sure that if there are several groups where all files have the same juliandate, the files from each polarimetry cycle are not mixed.
For example: even if there are two files for the same object and angle and they have the same date, the filename will distinguish if they belong to one cycle or other (Mrk241_0001R.fit vs Mrk241_0017R.fit).
This will not fix the fact that when the results are computed for those files, there will be several measurements for the same exact date and time. This can not be avoided since the time and date of the fits is exactly the same.