Closed AdamRJensen closed 1 month ago
avoid having modules named humidity, wind, pressure
Just an idea: does pvlib.atmosphere
already offer a suitable home for such functionality?
Using pvlib.atmopshere
seems like a good idea to me
Seems within the scope. From a couple of the examples already stated: humidity would support pvlib.atmosphere.gueymard94_pw
, pressure would support pvlib.atmosphere.get_absolute_airmass
(we do already have pvlib.atmosphere.pres2alt
there)
Just my thoughts...
To me, atmosphere is related to the 11 km column of aerosols above us, e.g., quantities such as airmass and precipitable water vapor. This seems in line with the current module title "Airmass and atmospheric models". Therefore, I would not expect to find, functions concerning near-ground weather in this module, thus I'm still leaning towards a new weather
module. Here's a few ideas of function types that might fit in this module: conversion between absolute and relative humidity, conversion of north/east wind speed to direction, etc.
PLEASE SHARE YOUR OPINION 👍Thumb up if you would like a new weather module 👎Thumb down if you want these function in the existing atmosphere module
@pvlib/pvlib-core, @echedey-ls, @RDaxini, @IoannisSifnaios, others
I'm not fond of the name weather
, for the sole reason that ModelChain
methods (most of them) have a weather
parameter.
I'm not strongly in favour or against. Creation of new modules seems a bit too ad hoc in general, so perhaps I would lean toward using atmosphere mainly because it avoids that. I also have no problem with the wind speed functions being in the temperature module because that's what they're used for in pv modeling
Here's UCAR's definition of weather:
Weather is the mix of events that happen each day in our atmosphere. Weather is different in different parts of the world and changes over minutes, hours, days and weeks.
I think that fits well with the weather
parameter in ModelChain
methods. I do not think it fits well with a module that implements physical and semi-empirical relationships between meteorological variables.
I prefer pvlib.atmosphere
to some extent, because it just makes sense to have it all near the same place. But I would heavily consider namespacing each set of functions, e.g.:
pvlib.atmosphere.
for general and common funcs like get_relative/absolute_airmass
, location.Location.get_airmass
, pres2alt
, alt2pres
pvlib.atmosphere.optical.
for specific aerosols and turbidity funcspvlib.atmosphere.humidity.
for water-based metricspvlib.atmosphere.wind.
for #2124 As always I'm thrilled that we have such a great community that's willing to give different perspectives on ideas, pushing pvlib to be greater than any one of us could achieve - thanks @adriesse, @wholmgren, @kandersolar, @cwhanse, @RDaxini!
@IoannisSifnaios let's proceed with adding the wind speed function in #2124 to the atmosphere module
2124 is adding a new function to estimate wind speed at different heights. In the PR there's a discussion about whether adding a new
wind
module makes sense given that we aren't sure there'll ever be more wind functions. @cwhanse brought up the idea of adding it to the temperature module (https://github.com/pvlib/pvlib-python/issues/2124#issuecomment-2221299596). Personally, I don't think adding it to the temperature module is a great fit either, as this would change the scope of this module significantly.Therefore, as a compromise, I suggest creating a new module named
weather
, that can host functions related to, you guessed it, weather (e.g., humidity, wind speed, pressure). Thetemperature
module can then be reserved for functions related specifically to module temperature, which I think was its original purpose (the documentation title is "PV temperature models").A potential new weather module would also be a great fit for #1744. Last, I could easily imagine other weather-related models being added in the future (and we avoid having modules named humidity, wind, pressure, etc.).
@IoannisSifnaios, @RDaxini