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

Bug in calculation of relative humidity if inputs are vapor pressure or specific humidity #435

Closed
dschlaep opened this issue Nov 15, 2024 · 0 comments · Fixed by #436
Closed
Assignees
Labels
Milestone

Comments

@dschlaep
Copy link
Member

Relative humidity is incorrectly calculated since https://github.com/DrylandEcology/SOILWAT2/releases/tag/v7.0.0
(as introduced with 7f9da8c) in two cases

  1. Daily weather inputs provide vapor pressure (and no relative humidity)
    This is the case with Daymet: the code currently calculates relative humidity as proportion [0, 1] instead of as percentage [0, 100]. For example:
bin/sw_test --gtest_filter=*Daymet*

WeatherFixtureTest.WeatherInputDaymet
calc hurs=0.733103: vp=0.300000, tas=-4.785000, svp=0.409219
...
calc hurs=0.691217: vp=0.410000, tas=-0.365000, svp=0.593157
...

This is caused by https://github.com/DrylandEcology/SOILWAT2/blob/34bd4bf69ce9b31f94e639cb1133eeceac1df3df/src/SW_Weather.c#L1900C21-L1901C88

yearWeather->r_humidity_daily[doy] = yearWeather->actualVaporPressure[doy] / svpVal;

which should correctly be

yearWeather->r_humidity_daily[doy] = 100 * yearWeather->actualVaporPressure[doy] / svpVal;
  1. Daily weather inputs provide specific humidity (and no relative humidity)
    This can be the case with MACA: the code currently calculates relative humidity in most cases as either 0 or 100% because of an incorrect estimate of saturated vapor pressure. For example:
bin/sw_test --gtest_filter=*MACAtype2*

WeatherFixtureTest.WeatherInputMACAtype2
calc hurs=100.000000: e = 1443.461744 / es = 0.000000, tas=-6.000000, huss=1.920000
...
calc hurs=0.000000: e = 1745.159779 / es = 6767936096406505376448512.000000, tas=3.445000, huss=3.070000
...

This is caused by https://github.com/DrylandEcology/SOILWAT2/blob/34bd4bf69ce9b31f94e639cb1133eeceac1df3df/src/SW_Weather.c#L1822C21-L1823C64

es = (6.112 * exp(17.67 * yearWeather->temp_avg[doy]) / (yearWeather->temp_avg[doy] + 243.5));

which should correctly be

es = 6.112 * exp((17.67 * yearWeather->temp_avg[doy]) / (yearWeather->temp_avg[doy] + 243.5));
@dschlaep dschlaep added the bug label Nov 15, 2024
@dschlaep dschlaep added this to the Release v8+ milestone Nov 15, 2024
@dschlaep dschlaep self-assigned this Nov 15, 2024
dschlaep added a commit that referenced this issue Nov 26, 2024
…edRelativeHumidity

Bugfix435: calculated relative humidity; count of missing weather LOCF

* Fix the calculation of relative humidity (close #435). Previously, relative humidity was incorrectly calculated if based on vapor pressure or specific humidity.

* Fix the count of days on which a missing weather value was replaced by a non-missing value from the preceding day for the method `"LOCF"` (last observation carried forward; close #437). Previously, any day with a missing weather value was counted.
dschlaep added a commit to DrylandEcology/rSOILWAT2 that referenced this issue Nov 26, 2024
See DrylandEcology/SOILWAT2#435

1) Updates to rSW2_set_weather_hist() are reflecting the changes in SOILWAT2's read_weather_hist()
* rSW2_set_weather_hist() now uses relativeHumidity1() to calculate relative humidity from vapor pressure -- fixing first part of SOILWAT2 bug #435
* rSW2_set_weather_hist() gained argument "elevation" and now uses relativeHumidity2() to calculate relative humidity from specific humidity inputs and elevation -- fixing second part of bug #435
** the conversion from specific to relative humidity is not exact, the code snaps estimated values within 100-150% to 100% relative humidity (with a warning)

Consequently,
* rSW2_setAllWeather() gained argument "elevation" which is passed to rSW2_set_weather_hist()

* onSet_WTH_DATA() calls rSW2_setAllWeather(): thus, functions that call onSet_WTH_DATA() are now required to previously set "elevation". These are
** rSW_CTL_obtain_inputs() calls onSet_WTH_DATA(): now, obtaining weather data occurs after obtaining "site" data that includes elevation
** rSW2_processAllWeather() calls onSet_WTH_DATA(): now, copies "elevation" from inputData argument to global object that is utilized by onSet_WTH_DATA()
*** dbW_generateWeather() calls rSW2_processAllWeather(): gained argument "elevation"
**** dbW_imputeWeather() calls dbW_generateWeather(): gained argument "elevation"

* rSW2_calc_SiteClimate() calls rSW2_setAllWeather(): gained argument "elevation"
** calc_SiteClimate() calls rSW2_calc_SiteClimate(): gained argument "elevation"

2) SOILWAT2's SW_WTH_read() now passes elevation as argument to readAllWeather(): thus, functions that call SW_WTH_read() are now required to previously set "elevation". These are
* rSW2_readAllWeatherFromDisk() calls SW_WTH_read(): gained argument "elevation"
** getWeatherData_folders() calls rSW2_readAllWeatherFromDisk(): gained argument "elevation"
*** dbW_addWeatherData() calls getWeatherData_folders(): gained argument "elevation"
**** dbW_addFromFolders() calls dbW_addWeatherData(): argument "MetaData" gained new column "elevation"

3) Update "extdata/example1" from SOILWAT2, i.e., "data_weather_maca" was renamed to "data_weather_maca-type1", "data_weather_maca-type2" is a new dataset
* update tests "Weather data sources" to handle new and renamed weather data sources
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant