-
Notifications
You must be signed in to change notification settings - Fork 295
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
Add meirink calib #2589
Add meirink calib #2589
Conversation
pdebuyl
commented
Oct 5, 2023
•
edited by mraspaud
Loading
edited by mraspaud
- Closes Add Calibration by Meirink et al for SEVIRI #2571
- Tests added
- Fully documented
Hello, this is more a "proof of concept" in terms of structure. I "hacked" the gain in (docs missing) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome, thanks for starting this! 👍 Looks good aready! I think since the coefficients are not within the file and also static, everything could be delegated to a "meirink calibration handler". For example:
class MeirinkCalibrationHandler:
def __init__(self, coefs=MEIRINK_COEFS):
self.coefs = coefs
def get_slope(self, platform, channel, time, version):
coefs = self.coefs[version][platform][channel]
return get_meirink_slope(coefs, time)
def get_version(self, calib_mode):
return calib_mode.split("-")[1]
class SEVIRICalibrationHandler:
def get_gain_offset(...):
...
if "MEIRINK" in calib_mode:
meirink = MeirinkCalibrationHandler()
version = meirink.get_version(calib_mode)
internal_gain = meirink.get_slope(version, self._platform_id, self._channel_name, self._scan_time)
I'm assuming here that the calibration mode includes the version calib_mode=meirink-2023
(as you proposed) and the coefficient dictionary has one extra layer for the version.
Maybe that's already enough for one PR. Channel specific coefficients are worth a separate PR and probably need more discussion on slack.
(typos from copying the coefficients over)
I put fixed values for the test, can you check it? I only check for the slope and not the offset, as the offset is taken from the input file and is not available within the test environment. |
To generate the tests, I wrote a sort parser for the text file that is now on the website of the MSG CPP team. https://msgcpp.knmi.nl/assets/custom_cal_aqua_c6_abs.txt The code: from datetime import datetime
with open('custom_cal_aqua_c6_abs.txt', 'r') as f:
lines = filter(lambda x: not x.strip().startswith('#'), f.readlines())
coef = {'Met8': {},'Met9': {},'Met10': {},'Met11': {}}
channels = ['VIS006', 'VIS008', 'IR_016']
for k in coef.keys():
for c in channels:
coef[k][c] = []
for oneline in lines:
oneline = oneline.split()
platform = oneline.pop(0).strip()
for c in channels:
coef[platform][c].append(float(oneline.pop(0)))
def get_slope(platform, channel, time):
A, B = coef[platform][channel]
DATE_2000 = datetime(2000, 1, 1)
delta_t = (time - DATE_2000).total_seconds()
S = A + B * 1.e-3*delta_t / 24 / 3600
return S/1000
examples = [
('Met8', datetime(2005, 1, 18)),
('Met8', datetime(2010, 12, 31)),
('Met9', datetime(2010, 1, 18)),
('Met9', datetime(2015, 6, 1)),
('Met10', datetime(2005, 1, 18)),
('Met10', datetime(2010, 12, 31)),
('Met11', datetime(2010, 1, 18)),
('Met11', datetime(2015, 6, 1)),
]
for platform, time in examples:
print(f"({platform}, {time.__repr__()}, ", [get_slope(platform, channel, time) for channel in channels], "),") |
Coefficients look good now, thanks! |
I added a comment for the units. Regarding the rest of your comment, it would be best to take them into account separately or after a discussion on slack, it this correct? Returning a dict would only have an effect on the content of the I have a draft with your proposed The dict is defined along |
Thanks!
Yes I think so. There are probably some use cases or implications that I'm not aware of.
That's correct, I just thought it would improve readability 🙂
Yes please! I think that would fit well in this PR. |
Co-authored-by: Stephan Finkensieper <stephan.finkensieper@dwd.de>
Looks very nice, just nitpicking now |
Hi @sfinkens I only left out the dict-type for the reply of As mentioned above, I have no preference for the API of |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Alright, looks good! Just a couple of small comments.
Oh, tests are failing... |
@pdebuyl thanks a lot for adding this! Only thing left for me are the failing tests, otherwise this looks good to me |
Codecov Report
@@ Coverage Diff @@
## main #2589 +/- ##
==========================================
+ Coverage 94.91% 94.94% +0.03%
==========================================
Files 351 354 +3
Lines 51215 51474 +259
==========================================
+ Hits 48611 48873 +262
+ Misses 2604 2601 -3
Flags with carried forward coverage won't be shown. Click here to find out more.
|
Hello @mraspaud thanks for also checking this. Version 3.11 still fails in the CI, no idea why. I also added a short documentation in the file. |
Really weird, windows is behaving... |
I triggered a rerun of the failed jobs, as I don't see how the changes here could affect the failing tests, and the tests pass correctly in other PRs. So I hope for a random glitch |
there is one "isort" issue in The failure in "CI / test (3.11, ubuntu-latest, true) (pull_request)" is a NumPy 2.0 issue. |
pushing the isort fix |
Yes, that's the unstable build, and we are aware of the problems there, but it's not blocking (ie we'll merge even if this is failing) |
OK, I have no further idea for the two failing tests. One is NumPy 2.0, which I guess is out of scope. The other is about the lack of type annotation for |
Yes, the type annotation for pre-commit is strange. I'm not aware that we are now requiring type annotation... @djhoese do you have an idea what this is about? |
The coefficients on the webpage https://msgcpp.knmi.nl/solar-channel-calibration.html were updated in place. The current set of coefficients were obtained in 2023, the code now reflects this correctly.
BTW I changed the "version" of MEIRINK-2013 to MEIRINK-2023 because the KNMI actually puts the updates of the coefficients "in place" on their web page. (see discussion on slack, but this is all in the PR message and added in the file for information). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thanks a lot!
Made a commit to make pre-commit's mypy (type annotations) checks work. |
Thanks @djhoese, but that looks like mypy is misbehaving. We have not configured it to enforce annotations, right? |
Yes we are. It is in pre-commit. The rest of satpy was made compliant (by me). And yes we've had this discussion before. Mypy will usually skip over functions/methods that don't have type annotations in the declaration, but I don't think that applies to globals. I think the complex structure of the content of this particular dictionary was just too much for mypy to guess at. |
ok... |
Only "3.11 ubuntu-latest true" failing. KeyError for orbital parameters at https://github.com/pytroll/satpy/actions/runs/6484922970/job/17609898950?pr=2589#step:10:268 Is this related to my PR? |
@pdebuyl it's not your PR, I'm merging this. |
Cool :-) A good day to contribute to satpy! |