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

inconsistent parameter names for mosmix data #615

Open
Elfe opened this issue Mar 6, 2022 · 5 comments
Open

inconsistent parameter names for mosmix data #615

Elfe opened this issue Mar 6, 2022 · 5 comments
Labels
parameter-naming All about the naming of parameters.

Comments

@Elfe
Copy link

Elfe commented Mar 6, 2022

Describe the bug
Mosmix data provides values for the current time or for the last x hours.
Some returned parameters include this information while others do not. (I just checked the _s data)
wind_gust_max_last_1h would be ok
while others like
sunshine_duration should have a last_1h
radiation_global should have a last_1h
(tx, tn need a last_12h)

Expected behavior
There should be a clear naming scheme for parameters.
nice_name_current or nice_name_now
nice_name_last_1h
or return the mosmix names

Desktop (please complete the following information):

  • OS: Linux Docker

Additional context
Renaming could break existing installations.

@gutzbenj
Copy link
Member

gutzbenj commented Mar 6, 2022

Dear @Elfe ,

I just had to figure what I was doing there.

I think my specific reasoning in case of sunshine_duration and similar parameters was:

  1. the time scale usually should be derived from the resolution
  2. the resolution in general is hourly for Mosmix so a standard parameter would refer to this last hour
  3. you've seen other parameters that have an attached _last_1h which I added because those parameters are given in multiple timescales e.g. last_1h, last_3h, ...
  4. generally speaking I tried not to add too many new parameters but find a general base/set

Now obviously some confusion came up between those two different "setups". From my perspective I'd propose removing those last_1h strings everywhere. Another option would be to add time specs to every parameter but that would include every single one of them.

Do you have further thoughts/ideas on this?

Cheers
Benjamin

@Elfe
Copy link
Author

Elfe commented Mar 7, 2022

I think a problem arises from the point values vs. last_1h values.
Removing those hints would not be a good thing imho.

Let's say I want to use check temperature for the afternoon at 14:15 then I look at the 14:00 point. Or in better cases try to interpolate 14:00 and 15:00.
With last_1h values I would have to check the 15:00 values. All these special cases would need to be glued in extra code :(

@gutzbenj
Copy link
Member

Hi again. Sorry for my late answer, have been struggling with some illness.

I understand the point you want to make here: values could be measured instantaneously (e.g. temperature at noon) versus averaged values (average temperature from 11:01 till 12:00). We honestly generally didn't care too much about this otherwise quite important meta information. The DWD has given detailed parameter information capturing used instruments but also information like is a timeseries constructed of instant values. They still name those parameters equally e.g. air temperature etc. We have omitted those information to prevent further splitting of parameters (e.g. temperature_air_instant_200).

Here are some other notes on behalf of your concerns:

  • meteorologic values should always be regared as a look backwards as they only reflect on the atmospheric state
    • for observations we are looking at the atmospheric conditions over a certain time and then reflect on it e.g. in the last 1 hour 10mm of precipitation hit the ground
    • for simulations e.g. earth system models we simulate the athmospheric state and then apply the same statistics on it, this is what mosmix forecasts are
    • let's call it a future perfect state e.g. "there will have been 10mm of precipitation at noon from the last hour" but you'd never say "there will be falling 10mm in the next 60 minutes" because of the nature of the variables - they are "only" abbreviated from the athmospheric conditions
    • hence I guess all variables should only reflect of the past X minutes/hours/days...
  • for your case (temperature at 14:15) you'd probably be fine taking the temperature of 15 o'clock as there is from my perspective no particular reason to assume a linear development between 14 o'clock and 15 o'clock. The development could be forced by something else as well...

What are your opinions on that?

cc @meteoDaniel @amotl @wetterfrosch

@gutzbenj
Copy link
Member

@Elfe should we once again elaborate on this? we may also have a small call.

@amotl amotl added the parameter-naming All about the naming of parameters. label Sep 3, 2022
@gutzbenj
Copy link
Member

annual update: @Elfe would you want to discuss the parameter naming again? I'm hoping to hear from you

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
parameter-naming All about the naming of parameters.
Projects
None yet
Development

No branches or pull requests

3 participants