psychrometrics in coolprop

[Alexander Pelham-Webb]

Hi Ian,

I've been following your work (https://ws680.nist.gov/publication/get_pdf.cfm?pub_id=921756) attempting to implement the code in the supplemental material to make some tools for the psychrometrics of CO2-rich mixtures, and had some comments and questions. I wasn't sure where else to put this, as it's not really part of CoolProp yet. I'm happy to do some work on helping to implement this, but I do have to warn you that I have 0 direct C++ experience, and can't do much more than infer how to change some things from limited python experience and an elementary understanding of types.

I had the most trouble with the wet bulb routines, especially the calculation of wet bulb temperature from T/p/x. I was able to partially work around this by floating the lower bound of the Brent solver with respect to the input temperature, as the solver was reporting negative densities on initializing. I've been setting the lower bound to be equal to the dewpoint on the assumption that a wet bulb temperature makes no thermodynamic sense below that. Your code is basically unchanged except for the added call to dewpoint_PX.

double wetbulb_TPX(double T, double p, double x_H2O)
{    
    // Get the enthalpy of the inlet gas phase
    shared_ptr<CoolProp::HelmholtzEOSMixtureBackend> HEOS_vap(new CoolProp::HelmholtzEOSMixtureBackend(all_components));
    HEOS_vap->specify_phase(CoolProp::iphase_gas);
    HEOS_vap->set_mole_fractions(humid_air_composition(x_H2O));
    HEOS_vap->update(CoolProp::PT_INPUTS, p, T);    
    double h = HEOS_vap->hmolar(); // [J/mol_ha]
    // set the Brent lower bound to be equal to dew point - wet bulb makes no sense below this ??
    double a = dewpoint_PX(p, x_H2O);
    // Construct the residual class
    WetBulbResidual__TPX resid(T, p, h, x_H2O);
 
    double Twb = CoolProp::Brent(resid, a, T, DBL_EPSILON, 1e-12, 100);
    return Twb;
}

It's ok for most humidities from slightly below freezing to nearly boiling, but fails for cold and dry and 95+C and dry (< 10% RH). It also doesn't seem to be stable, as my nice home pc has no problem with it, but my garbage work pc fails at milder temps, valid from roughly 35 - 90 C. The failure in each case occurs in the polisher - omega can't take a valid step.

Is my assumption that wet bulb cannot be lower than dew point valid? Is there another way I should be approaching setting up the solver? Or is this an issue with floating point arithmetic?

The other thing that's giving me hangups is how to develop utilities for relative humidity, especially RH from composition and vice versa. I understand there are multiple possible definitions which aren't strictly equivalent except at 0 & 100%. If you were approaching this problem, would you select a standard definition and stick to it, or allow for a choice of definition? If one allows for a choice of definition, it seems to me that there must be a standard internal representation, so one would have to start implementation from a consistent standard definition eg. water activity or relative fugacity.

For reference, I am using CoolProp 6.2 nightly build from the last week of February and the supplemental material code from the I.J.Ref. publication of your paper, with the above change. My test mixture on a dry basis is 95% CO2, with the balance air - I evenly split the 400 ppm CO2 from standard air into the N2 and O2 fractions.

((1 - CO2conc)*0.7810707,(1 - CO2conc)*0.2095969,(1 - CO2conc)*0.0093324,CO2conc)

[Ian Bell]

Hi Alex,

It would indeed be great to see this code get into CoolProp, but given my current constraints I am afraid I can't be too much help with this.  If you do the heavy lifting, maybe Jeff Henning can loop back with you and help you with the C++ stuff.  I should mention that for conventional psychrometric calculations, you're probably still better off with the implementation of HAPropsSI in CoolProp since it is more accurate. To improve the accuracy of the model in my code, we would need new models specifically tuned for psychrometric calculations.  That's doable, and on my long-term plan.  But not in the short term.

I forget, how did I handle RH in my paper?  I would stick to that and go with it.  I recall that Allan and I discussed this at some length.  The multiple possible definitions of RH is indeed problematic.

Best,

Ian

--
You received this message because you are subscribed to the Google Groups "coolprop-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to coolprop-user...@googlegroups.com.
To post to this group, send email to coolpro...@googlegroups.com.
Visit this group at https://groups.google.com/group/coolprop-users.
For more options, visit https://groups.google.com/d/optout.

[Alexander Pelham-Webb]

Hi Ian,

I'm using HAPropsSI to validate that the tools actually make sense, and also to knock some silly ideas out of people's heads here (they've been using some suspect air correlations well outside of the range they were fit to, and for a non-air mixture!). You used the ideal gas, in line with ASHRAE and WMO; mole fraction == partial pressure / total pressure == RH(%). I've stuck to this for now.

Digging through the HAPropsSI code, it looks like I should try to structure the generalized module similarly (also cleared up my question about wet bulb solver bounds). That should make it easiest to maintain usage syntax and seems to be conducive to swapping humidity definitions as well. This is what you mean by 'heavy lifting,' correct? Extending the existing code to match the HAProps outputs and massaging to maintain the same syntax (this is the point where I would definitely need help)? So users could swap out HAPropsSI for HGPropsSI (or something similar) plus a dry composition vector and call it a day. I'll take this as my starting point unless you have a different suggestion. For the more in-depth C++ integration and speaking with Jeff, I should move to github?

Lastly, I'm a bit confused when you refer to new models - my impression from the paper was increasing accuracy was a matter of refitting interaction parameters to focus on the vapor phase, which would be some extra .json entries and a flag for which set to use in the mixture backend (the easy part that is). Did I miss something, that this module would have to implement something else?