Wrong values for temperature-dependent sigma of water in PC-SAFT

[pw0908]

The parameters used for the sigma of water here is not the default one from Cameretti and Sadowski (they seem to have been obtained from a paper by Baird et al.):

CoolProp/src/Backends/PCSAFT/PCSAFTFluid.cpp

Lines 58 to 66 in ffa5a27

	void PCSAFTFluid::calc_water_sigma(double t) {
	if (t > 473.16) {
	throw ValueError("The current function for sigma for water is only valid for temperatures below 473.15 K.");
	} else if (t < 273) {
	throw ValueError("The current function for sigma for water is only valid for temperatures above 273.15 K.");
	}
	params.sigma = 3.8395 + 1.2828 * exp(-0.0074944 * t) - 1.3939 * exp(-0.00056029 * t);
	}

The actual values should be:

params.sigma = 2.7927 + 10.1100*exp(-0.01775*t)-1.41700*exp(-0.01146*t)

[ibell]

Zach Baird (@zmeri ), do you have a comment here? Perhaps we need to update the documentation that you implemented your parameters rather than the canonical ones?

[zmeri]

Yes, for our article we needed to calculate properties at higher temperatures, so the original values given by Cameretti and Sadowski did not work because, if I remember correctly, they were only fit for data up to about 100 C. I remember comparing the results of both equations and for lower temperatures they gave the same result to within the accuracy of the PC-SAFT model, if my memory isn't failing me. Are you seeing any significant differences in the results when using ePC-SAFT with our temperature dependent equation for sigma?

[pw0908]

I've actually been doing benchmarking for ePC-SAFT between the pcsaft and CoolProp implementations (for my own implementation in Clapeyron.jl). They don't agree to machine accuracy. The Clapeyron.jl implementation agrees to machine precision with CoolProp though, when using the same temperature-dependent segment diameter.

I also believe the example given in the pcsaft implementation uses the standard correlation?

On that note: how certain are you that your implementations reproduce the literature results? Particularly from the ePC-SAFT revised paper. Despite agreeing to machine precision with CoolProp, I can't reproduce the paper's results and I couldn't find a way to reproduce the paper's results from CoolProp.

[zmeri]

pcsaft and CoolProp use essentially the same code for ePC-SAFT. I wrote the pcsaft code and then copied it over to CoolProp and made the necessary changes to fit it into the CoolProp architecture. I tested the CoolProp implementation against pcsaft, so they should give quite similar results. Are you testing for machine accuracy with values that do not depend on the density? I have before found that differences can come because of differences in when the solvers decide they have achieved an acceptable value and stop. If I remember correctly, there is also an iteration loop to find a value for the association term, so it can also be harder to get exactly equal results (to machine accuracy) for mixtures with the association term.

For both pcsaft and CoolProp I wrote unit tests to check that literature results are reproduced and these are included in the code on Github. Given though that Held and his team have not released their own ePC-SAFT code, I had no way to check ePC-SAFT to machine accuracy, so in the tests I checked they were within expected error limits to the literature values given in the ePC-SAFT articles. I did get some data from Held to check a single datapoint, and I remember that some differences came because he used more decimal places for parameters than were reported in the article. For instance, I remember that in one case a value was given as 3.60 (maybe a sigma value) in the article, but Held used something like 3.5995 in the calculation he sent. Small differences like this don't significantly affect the results, but could cause differences greater than machine accuracy.

[pw0908]

These are the exact benchmarks I ran, along with the conditions, parameters and outputs. I compared a_res, Z and the fugacity coefficients (I couldn't obtain them with CoolProp). The agreement is pretty much spot on between CoolProp and Clapeyron, but there are some discrepancies with pcsaft.
benchmarks_epcsaft.xlsx

Despite getting this agreement with CoolProp and pcsaft, I cannot, for the life of me, reproduce the results from Held's 2014 paper, specifically the osmotic coefficients. Since one can't obtain fugacity coefficients from CoolProp, I couldn't obtain the osmotic coefficients. As for pcsaft, the osmotic coefficient solver seems broken? I did get in touch with Held and I am waiting to hear back regarding benchmarks.

Addressing the original issue here (@ibell): I still think, since it's more widely used, the original Cameretti correlation should be used.

[pw0908]

Just wanted to give you both an update: I found out what is wrong with all our implementations of ePC-SAFT. Turns out, within the DH theory, the temperature-dependent hard-sphere diameter is used, rather than just sigma. I managed to get this clarified after a few emails with Christoph Held. I am now able to reproduce their results.

[zmeri]

Thank you for sharing this @pw0908. Is this the commit where you fixed it in Clapeyron.jl?
ClapeyronThermo/Clapeyron.jl@bf1c770

I am trying to figure out where the change needs to be made, but I don't see exactly where the temperature dependence comes in. Does the temperature-dependent hard-sphere diameter need to be used for calculating chi and sigma_k in the ion term of ePC-SAFT?

[pw0908]

That is indeed the commit where I fixed it. I allowed the ion diameter to be a kwarg instead where, for ePC-SAFT specifically, we can swap in the temperature-dependent hard-sphere diameter instead.

Indeed, everywhere you would normally see sigma_k in DH, you must now use HSd_k.