That is how you calculate RH. You can’t use RH to calculate RH . The two formulas use the Saturated Vapor Pressure and the Dry Vapor Pressure to calculate RH.
WeatherFlow, is using neither of those formulas. That’s part of what started this. WeatherFlow is using a THIRD formula that is not related to weather.gov.
dewpoint is derived by WF by calculation using those two sensors
The wf derived_measurements formula uses RH sensor and dewpoint (calculated) temperature. It would be nice if they said ‘dewpoint’ on their page to make it clearer.
the weather.gov formula uses the same dewpoint (calculated) and the T (air) sensor to go the other way, since you can get any missing item of air temp / dewpoint / RH if you have two of the three measured
I don’t see a problem at all, other than not knowing where the WF formula on the derived measurements page actually came from. Mathematically the two formulas get the same answer (or really close), both based on the physical sensor data the Air has available to it.
Sorry, but I can’t find a scenario where that is true.
Give me input data that proves that please.
the WF formula takes ‘observed’ temp and observed humidity in as input
the weather.gov formula takes in ‘dewpoint’ as input
we can calculate dewpoint from observed temp and observed humidity
Consider an observed temperature of 15 C and 50% RH…
that’s a dewpoint of 4.65746100514 C
So lets run the data:
the weatherflow formula calculates a VP of 8.52024726897 mb from T = 15 and H = 50
the weather.gov formula calculates a VP of 8.51940740716 mb from Dp = 4.65746100514
I don’t see any difference.
I think you’re feeding dewpoint in one place where you should be feeding observed temperature, or vice versa. I can’t find any way to show calculations that aren’t close if I feed the two formulas the right data.
Here is the test code with results. Thank you all for sticking with me and pointing put where I went wrong. A special thanks to @vinceskahan for not giving up on me.
T = 15.0;
H = 50;
Dp = 4.65746100514;
E 8.51940740716102 <= weather.com
Rh 8.52024726897465 <= WeatherFlow
Es 8.513232793184109 <= Herman Wobus
_calcVaporPressureE(Dp);
_calcVaporPressureRh(T, H);
_calcVaporPressure(Dp);
function _calcVaporPressureE(Dp) {
// (dew point in C)
Dp = parseFloat(Dp);
let a = (7.5 * Dp) / (237.3 + Dp);
let E = 6.11 * Math.pow(10, a);
console.log('E ' + E);
return E;
}
function _calcVaporPressureRh(T, H) {
// (temp in C, humidity)
T = parseFloat(T);
let a = (17.67 * T) / (243.5 + T);
let E = (H / 100) * 6.112 * Math.exp(a);
console.log('Rh ' + E);
return E;
}
function _calcVaporPressure(T) {
// https://wahiduddin.net/calc/density_altitude.htm
// (temp in C)
let Eso = 6.1078;
let C0 = 0.99999683;
let C1 = -0.90826951E-02;
let C2 = 0.78736169E-04;
let C3 = -0.61117958E-06;
let C4 = 0.43884187E-08;
let C5 = -0.29883885E-10;
let C6 = 0.21874425E-12;
let C7 = -0.17892321E-14;
let C8 = 0.11112018E-16;
let C9 = -0.30994571E-19;
let Pol = C0 + T * (C1 + T * (C2 + T * (C3 + T * (C4 + T * (C5 + T * (C6 + T * (C7 + T * (C8+ T * (C9)))))))));
let Es = Eso * Math.pow(Pol, -8);
console.log("Es " + Es);
}
Just FYI. I deleted some of my incorrect posts, not to hide my mistakes but to remove confusing information. No need for my mistakes to screw up others.
FWIW, I put up a github repo (here) with my python code and sample output, if anybody is interested. The python code can be very easily converted to javascript if you’re so inclined. Should be obvious.
To run, just download the .py file and run “python filename.py” to generate the same thing as the sample output file I have in the repo there…
Phew! Glad you guys figured it out. I wasn’t sure when we’d have time to dig back into those formulas and figure out where the issue was… This is a great example of the developer community helping each other. Good work!!
Actually, all “derived parameters” are calculated on server-side. The only quasi-exception (I think) is “sea-level pressure”, which is calculated server-side along with the rest of the “station observation” values, but it’s also computed client-side (in the apps) for the graph display. And that’s only because the API does not currently return any time series “derived parameters” (although it probably will one day).