Bug in derivatives from Matlab

[Astrinus]

I'm trying to get derivatives (partial and saturation) from Matlab.
I'm using the low-level interface and I can update the state and get properties like density, enthalpy and so on; however, when I issue

as.first_partial_deriv(CoolProp.iDmass,CoolProp.iHmass,CoolProp.iP)

to get d(rho)/d(H)|P, I get the following messages:

Warning: NewPointerObj problem. clientdata NULL. guessed CoolPropDbl 
Warning: NewPointerObj problem. creating SwigRef as opposed to
CoolPropDbl 

ans = 

<Swig Object of type _p_CoolPropDbl, ptr=4642573344, own=1>

and I don't know what I should do with this (I guess) pointer, since Matlab has no way I could find to dereference it.
Storing the object in a variable and trying to fiddle with it didn't help.
The same happens with first_saturation_deriv: this behaviour seems very different from their C++ counterparts, which return a number.

[ibell]

Actually, I think I see the problem with this particular case, and I think
I can fix it (exposed function should use doubles instead of CoolPropDbl)

Or you could switch over to a more well constructed language like python.
Everything works fine in python, it is what the two main developers work in
most of the time.

On Fri, Apr 3, 2015 at 2:18 AM, Astrinus notifications@github.com wrote:

I'm trying to get derivatives (partial and saturation) from Matlab.
I'm using the low-level interface and I can update the state and get
properties like density, enthalpy and so on; however, when I issue

as.first_partial_deriv(CoolProp.iDmass,CoolProp.iHmass,CoolProp.iP)

to get d(rho)/d(H)|P, I get the following messages:

Warning: NewPointerObj problem. clientdata NULL. guessed CoolPropDbl
Warning: NewPointerObj problem. creating SwigRef as opposed to
CoolPropDbl

ans =

<Swig Object of type _p_CoolPropDbl, ptr=4642573344, own=1>

and I don't know what I should do with this (I guess) pointer, since
Matlab has no way I could find to dereference it.
Storing the object in a variable and trying to fiddle with it didn't help.
The same happens with first_saturation_deriv: this behaviour seems very
different from their C++ counterparts, which return a number.

—
Reply to this email directly or view it on GitHub
#573.

[Astrinus]

The problem is that this is part of a bigger project which uses Simulink as well and requires lot of work hours to be ported in Python (which I know, but the others not). So porting is not feasible.

[ibell]

Yeah if you are using Simulink, you are stuck with MATLAB. I'll fix this issue.

[ibell]

Got it - a one line fix in the end