Division by zero when building CO2 tables

[jowr]

I think there is a problem with the critical inputs for CO2. This code from the tabular backend causes a division by zero error that gets past all error handling:

AS->update(PQ_INPUTS, AS->p_critical(), 1);
std::size_t i = N-1;
pV[i] = AS->p(); TV[i] = AS->T(); rhomolarV[i] = AS->rhomolar();
hmolarV[i] = AS->hmolar(); smolarV[i] = AS->smolar(); umolarV[i] = AS->umolar();

I do not have the time to dig deeper at the moment, but it seems like the issue appears for CO2 but not for R134a. Furthermore, the problem does not show up with the statically linked code. It only occurs in a Windows DLL.

[ibell]

Ok, this is the old fpu error flags clearing beast again on windows. Which exact calls cause this problem? I can guess, but I suspect that we need to add reset_fpu(); calls prior to returning from all functions that are in the AbstractState_XXX family in the DLL.

Relatedly, it is necessary that we allow for calculations AT the critical point for CO2 and water, for which I have a solution, though I don't like it all that much

[jowr]

There is no special call involved, it is the table generation. More specifically, it is the last point - the (in many ways) critical point.

[ibell]

Yup, I know how to fix this problem. Annoyingly, since we made tau and
delta const in the critical helmholtz term, I need to do some more serious
rearchitecture.
On Nov 25, 2015 5:18 AM, "Jorrit Wronski" notifications@github.com wrote:

There is no special call involved, it is the table generation. More
specifically, it is the last point - the (in many ways) critical point.

—
Reply to this email directly or view it on GitHub
#879 (comment).

[jowr]

Fine, but I still do not understand why the code works with statically linked files and does not work with a shared library. Is this really just the floating point error stack that screws things up on Windows?

[ibell]

Yup, what are calling the dll from? Clearly its something that checks the
fpu bits and errors out if they haven't been reset (excel and vb for
instance). Can you first try to call the reset fpu function in the
abstract state functions? That should do it, though I will fix that non
analytic issue at critical point.
On Nov 26, 2015 12:45 PM, "Jorrit Wronski" notifications@github.com wrote:

Fine, but I still do not understand why the code works with statically
linked files and does not work with a shared library. Is this really just
the floating point error stack that screws things up on Windows?

—
Reply to this email directly or view it on GitHub
#879 (comment).

[jowr]

Fine. I built a new interface that stores a certain number of abstract state objects with tables and uses a std::string map to switch between them. This DLL then gets called from a Delphi GUI.

I have tried to reset the fpu in the library, but had no luck with that. I might give it another try in the abstract state functions.

Good luck with the non-analytic terms. I started to work on that as well, but it ended up being a mess made of if-else clauses, which makes the sources very hard to read...

Am I right that it is the power function from the math library that causes the problems?

[ibell]

I think the issue is that if the floating point processor ever realizes that it did a division by zero anywhere (pow(0.0,-1.0) or 2.0/0.0 sorts of calculations), it sets the division by zero bit. If you don't reset that flag using the reset_fpu() function in the CoolPropLib.cpp, tools that check the FPU errors (like Excel, and evidently Delphi), will die without having thrown an exception.

The solution is to fix the non-analytic terms at the critical point. I know how to do that, but it's annoying since we make tau and delta be const. I'm going to "fix" that. Watch this space. It's going to penalize the speed just a tiny bit I think, but it should fix this problem.

[ibell]

Ok, I think this should fix it once and for all. Lemme know.

[ibell]

@jowr potentially related to #891 - do you still get this error after I "fixed" this issue?

[jowr]

Yes, this one is for sure related to #891, #877 and #892 . I'll collect everything in #877 .