RTTOV 13 clouds - Githubissues

hkershaw-brown commented 7 months ago

Description:

Initialize rttov profile cloud arrays to zero for profiles to fix the bug reported in #542

the bug occurs when the cloud type changes from one vertical profile to the next. In these cases, when the cloud type changes between calls, the current cloud type is assigned the proper water values for the current profile, however, the previous cloud type from the previous profile is retained, and is assigned to the current call -- thus the current profile is assigned both the current cloud water values, but erroneously assigns the previous profile cloud type water values.

see https://github.com/NCAR/DART/issues/542#issuecomment-1852894675 for discussion on hardcoded wfetc value. Needs a science review, should the wfetc value be a namelist option?

HIMAWARI 8 and 9 changed to QTY_BRIGHTNESS_TEMPERATURE - need a science review on this

Fixes issue

fixes #542 fixes #625 fixes #630

Types of changes

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Documentation update

Documentation changes needed?

[x] My change requires a change to the documentation. (wfetc)
- [ ] I have updated the documentation accordingly.

Tests

Please describe any tests you ran to verify your changes.

Tested with Joseph's case /glade/work/bmraczka/DART/models/wrf/RTTOV_bug

Checklist for merging

[ ] Updated changelog entry
[ ] Documentation updated
[ ] Update conf.py

Checklist for release

[ ] Merge into main
[ ] Create release from the main branch with appropriate tag
[ ] Delete feature-branch

Testing Datasets

[ ] Dataset needed for testing available upon request
[ ] Dataset download instructions included
[ ] No dataset needed

hkershaw-brown commented 6 months ago

some confusion for users over the source: https://github.com/NCAR/DART/blob/52e6e45f8f6ff07a90227766c8de72f1474162f2/observations/forward_operators/obs_def_rttov13_mod.f90#L595

fix: obs_def_rttov13_mod.f90

aslo comment: https://github.com/NCAR/DART/blob/e5ba91df924e3901b4ab99c831beddc78d80cf4e/observations/forward_operators/obs_def_rttov13_mod.f90#L632

I don't think we want to change the name of the module to 'module obs_def_rttov13_mod' because we don't want people compiling 12 and 13 into dart.

braczka commented 6 months ago

some confusion for users over the source:

https://github.com/NCAR/DART/blob/52e6e45f8f6ff07a90227766c8de72f1474162f2/observations/forward_operators/obs_def_rttov13_mod.f90#L595

fix: obs_def_rttov13_mod.f90

aslo comment:

https://github.com/NCAR/DART/blob/e5ba91df924e3901b4ab99c831beddc78d80cf4e/observations/forward_operators/obs_def_rttov13_mod.f90#L632

I don't think we want to change the name of the module to 'module obs_def_rttov13_mod' because we don't want people compiling 12 and 13 into dart.

Yes, it's confusing if error call is coming from rttov when actually using rttov13. In favor of fixing error call if possible, leaving the module name the same.

hkershaw-brown commented 6 months ago

some confusion for users over the source: https://github.com/NCAR/DART/blob/52e6e45f8f6ff07a90227766c8de72f1474162f2/observations/forward_operators/obs_def_rttov13_mod.f90#L595

fix: obs_def_rttov13_mod.f90 aslo comment: https://github.com/NCAR/DART/blob/e5ba91df924e3901b4ab99c831beddc78d80cf4e/observations/forward_operators/obs_def_rttov13_mod.f90#L632

I don't think we want to change the name of the module to 'module obs_def_rttov13_mod' because we don't want people compiling 12 and 13 into dart.

Yes, it's confusing if error call is coming from rttov when actually using rttov13. In favor of fixing error call if possible, leaving the module name the same.

fixed in d63286d3892f9e95257cf3cddc977e890209413e

braczka commented 6 months ago

Just following up on previous discussion point about BT sensitivity to wfetch values (https://github.com/NCAR/DART/pull/602#discussion_r1453555646). I could not detect significant differences when varying wfetch from 100000 to 10 for either cloudy or clear sky regions in this simple domain example. This gives me confidence for now we can just document the wfetch issue, suggest the spatiotemporal wfetch approach for the future, keep the code for now as a wfetch namelist option.

hkershaw-brown commented 5 months ago

Just following up on previous discussion point about BT sensitivity to wfetch values (#602 (comment)). I could not detect significant differences when varying wfetch from 100000 to 10 for either cloudy or clear sky regions in this simple domain example. This gives me confidence for now we can just document the wfetch issue, suggest the spatiotemporal wfetch approach for the future, keep the code for now as a wfetch namelist option.

Great, thanks for looking at this Brett.

NCAR / DART

RTTOV 13 clouds #602