Hi there,

I was looking into integrating a REFPROP function to calculate gas density into an existing LabWindows program. I noticed there were existing solutions for LabView and was wondering if you knew of existing examples pertaining to LabWindows?

Hello CoolProp Team,

I'm having trouble linking REFPROP-cmake with CoolProp.

I followed all the instructions to build both CoolProp and REFPROP-cmake, from the following readme's without any errors.

Using the 64-bit instructions
http://www.coolprop.org/coolprop/wrappers/SharedLibrary/index.html#shared-library
https://github.com/usnistgov/REFPROP-cmake

I added both CoolProp and REFPROP-cmake directories in a config file under the ld.so.conf.d directory, which are recognized by my system when using the ldconfig -p command. Where the following snippet are the relevant libraries in question.

I found a sample c++ script from the CoolProp documentation (first link) and was able to compile and execute the original successfully, so I modified it slightly in hopes it would just link with REFPROP but I was wrong.

#include <iostream>
#include "CoolPropLib.h"
#include "CoolProp.h"
#include "REFPROP_lib.h"

//Simple example
int main(){
    double T{293.15};
    double P{1e5};
    double res{CoolProp::PropsSI("H", "T", T, "P", P, "REFPROP::Water")};
    std::cout << "Enthalpy: " << res << std::endl;
}

I compiled the sample file using the following linkages which resulted in no runtime errors. The additional linkages are locations in CoolProp include and externals directories, including REFPROP-cmake's externals and build directories.

g++ -std=c++11 -Wall -O2 -o snaple -DCOOLPROP_LIB -ICoolProp/include -ICoolProp/externals/fmtlib snaple.c -IREFPROP-cmake/externals/REFPROP-headers -IREFPROP-cmake/build CoolProp/build/libCoolProp.so.6 REFPROP-cmake/build/librefprop.so -ldl

When I run the compiled code, all I get is this. I know that the REFPROP 10.0.0.2 is 64 bit and I made sure everything is 64 bit. The paths are defined in the search but I am unsure whether I need to implement other parameters in this simple example code.

Good news: It is possible to use REFPROP on your system! However, the library
could not be loaded. Please make sure that REFPROP is available on your system.

Neither found in current location nor found in system PATH.
If you already obtained a copy of REFPROP from http://www.nist.gov/srd/,
add location of REFPROP to the PATH environment variable or your library path.

In case you do not use Windows, have a look at https://github.com/jowr/librefprop.so
to find instructions on how to compile your own version of the REFPROP library.

ALTERNATIVE_REFPROP_PATH:
ERROR: Could not load REFPROP (librefprop.so) due to: /opt/refprop/librefprop.so: cannot open shared object file: No such file or directory. Make sure the library is in your system search path. In case you run 64bit Windows and you have a REFPROP license, try installing the 64bit DLL from NIST.
Enthalpy: inf

If it is possible, I would really like a way to load different DLLs and fluid folders. Does it make sense to work on this or are there any hardcoded names inside the shared library?

Hi
Dont find definition for HEATdll in REFPROP_lib.h

Hello, Mr. Bell, thanks for your time.

I have read and tested the C++ program like "main.cpp" in this repository using Visual Studio Code. An error in header file "REFPROP_lib.h" is reported, which is "A variable "t" is not defined and assigned". Its location is in line 759, column 45.

In addition, I'm studying the real time simulation of thermodynamic time-varying system based on Simulink. Thermophysical properties of working fluids are planned to be obtained by calling C-style refprop routines. I would like to ask if there is a refprop header file based on C and an example of calling refprop in C program.

Besides, I want to know if there is an embedded system development case that calls refprop in real-time target machine which from Speedgoat Co.

Thanks.

Hi, what about renaming the repo to 3rd-party-headers? We could collect custom header files here or should we make separate repos for other headers?

I'm running the main.cpp file but I get an error when trying to open the R32.FLD file

101 herr: [SETUP error 101] Error in opening file for component 1: filename = R32.FLD

I am using Linux (Ubuntu) and g++ to compile the code. I have copied the fluid and mixture files over from a Windows installation so I was wondering whether the files aren't compatible?

It looks like some commits are missing from the master branch. Comparing REFPROP_lib.h the HEAD and the logs suggests that fcb2c24, 183a5cd and 5bd15ef have somehow been removed.

Example: The changes from fcb2c24 in line 162 in REFPROP_lib.h are not present in the current master branch...

First arg should be double *, not DOUBLE_REF

Hi, having a small issue using the REFPROP_lib.h header.

When compiling, I am getting errors saying that there are undefined references, to "WMOLdll" for example.

At the top of my C code, I am using

#define REFPROP_PROTOTYPES
#include "REFPROP_lib.h"
#undef REFPROP_PROTOTYPES

I am calling the functions like this:
XMASSdll(xmol, xkg, &molwt)
And getting this as my compilation output:

func.c: In function 'myfunc':
func.o: In function `myfunc':
func.c:(.text+0xfc): undefined reference to `WMOLdll'
func.c:(.text+0x12a): undefined reference to `CRITPdll'
func.c:(.text+0x1c8): undefined reference to `TPFLSHdll'
func.c:(.text+0x2c1): undefined reference to `TSFLSHdll'
func.c:(.text+0x594): undefined reference to `TSFL1dll'
func.c:(.text+0x60e): undefined reference to `THERMdll'
func.o: In function `myfunc2':
func.c:(.text+0x9c6): undefined reference to `XMASSdll'
func.c:(.text+0xa2f): undefined reference to `TPRHOdll'
func.c:(.text+0xa72): undefined reference to `CVCPdll'
func.c:(.text+0xb7f): undefined reference to `THERM2dll'
func.c:(.text+0xc7d): undefined reference to `TRNPRPdll'
collect2: error: ld returned 1 exit status

Am I missing something?

Also, in the repo, there is no C example, only C++, would you consider adding that?

Thanks

This might be a REFPROP issue, I'm not sure. However, I have had a Mathcad wrapper written for a decade that links in a compiled REFPROP.LIB and makes the external function calls directly. This worked great, but I've had to recompile each version of REFPROP over the years into a new LIB and link that into a new wrapper version.

Then I figured out how CoolProp was calling the REFPROP.DLL and REFPROP64.DLL directory. This is brilliant! So I rewrote my wrapper and, although it works, the Mathcad 15 (32-bit) wrapper is about 100X slower than the direct calls to a linked in Fortran. Everything I've read indicates that calling the DLL shouldn't be any slower than direct calls. Scratching my head.

Then I compiled the exact same code as a Mathcad Prime wrapper, which is 64-bit and makes calls to REFPROP64.DLL instead. I'm back up to speeds comparable to the original direct linked code.

Any ideas why making the calls to the 32-bit REFPROP.DLL would be that much slower? I have a Mathcad 15 verification worksheet that used to process in less than a minute and now takes hours! The Mathcad Prime version (same source code, 64-bit compile/link) runs the equivalent worksheet in less than a minute. Any thoughts on how I can debug this?

Thanks.

I am using the REFPROP headers in order to call the DLLs from another C++ project. I am using the context that is provided in the main.cpp file, in order to point to the location of "fluids" folder.

char mypath[] = "C:\\Program Files (x86)\\REFPROP\\";
SETPATHdll(mypath, 400);

I am getting "Access Violation Writing Location" error for SETPATHDLL call.

Add a new C++ object that manages access to the REFPROP library. This should cover some of the code from https://github.com/CoolProp/CoolProp/blob/master/src/Backends/REFPROP/REFPROPMixtureBackend.cpp and is closely related to CoolProp/CoolProp/issues/354 and jowr/librefprop.so#21

Could we please find a way to document which version of REFPROP is intended to be used with this repository? People with old REFPROP versions might find it useful to either have tags or branches for old REFPROP versions. We could also include some more macros to conditionally define the new functions, but I am afraid that this makes the code even harder to read.