Use of triple point of water in GetSatVapPres

[dmey]

This PR introduces the use of triple point of water in GetSatVapPres to make the functions more physically correct and simplifies considerably the NR convergence procedure in GetTDewPointFromVapPres. This issue arises from the discontinuity at the freezing point of water.

[dmey]

@didierthevenard should the other couple of instances of freezing point of water also be replaced?
E.g.

psychrolib/src/python/psychrolib.py

Line 590 in af24c1c

if TWetBulb >= 32:

If not, to make the code cleared we should probably make this into a parameter and call it something like FREEZING_POINT_WATER_{SI, IP}

[didierthevenard]

For completeness, this comment should be copied to all other languages.

[didierthevenard]

One small change requested - propagate to other languages the comment made in Python about the justification for using the triple point of water. Other than that, no issue found.

[didierthevenard]

Regarding comment #36 (comment): I have checked, and please tell me if I am wrong, but I can find only one place where the freezing point of water is used, that is, in GetHumRatioFromTWetBulb(). I have checked and the formulae in that function do present a discontinuity at the freezing point. However changing the threshold to the triple point does not resolve the discontinuity so I am not sure if this is related at all to the issue we had in GetSatVapPres() - likely not. So no change needed. The discontinuity does not seem to cause any issues anyway. As for changing the values 32 and 0 to FREEZING_POINT_WATER I think it would be a good idea. For consistency I suggest that the constant could be declared at the same time as TRIPLE_POINT_WATER, despite the fact that it is used only in one function and could be declared there locally instead.

[dmey]

Regarding comment #36 (comment): I have checked, and please tell me if I am wrong, but I can find only one place where the freezing point of water is used, that is, in GetHumRatioFromTWetBulb(). I have checked and the formulae in that function do present a discontinuity at the freezing point. However changing the threshold to the triple point does not resolve the discontinuity so I am not sure if this is related at all to the issue we had in GetSatVapPres() - likely not. So no change needed. The discontinuity does not seem to cause any issues anyway. As for changing the values 32 and 0 to FREEZING_POINT_WATER I think it would be a good idea. For consistency I suggest that the constant could be declared at the same time as TRIPLE_POINT_WATER, despite the fact that it is used only in one function and could be declared there locally instead.

That's right -- agreed. And sure, have now added FREEZING_POINT_WATER_{IP, SI}.

Propagated note about using the triple point of water to the other languages and I retested VBA locally. I have re-requested your review. After this we can prepare for the new release. Let me know if you want to consider this a bugfix or not as this to me would be a patch version 2.1.1 -- i.e. point 3 from the list below (https://semver.org/):

1. MAJOR version when you make incompatible API changes,
2. MINOR version when you add functionality in a backwards-compatible manner, and
3. PATCH version when you make backwards-compatible bug fixes.

[didierthevenard]

No issues found, thanks for your work on this!
As for the version, yes this can be a patch.