Welcome to CoolProp

CoolProp is a thermophysical property database and wrappers for a selection of programming environments. It offers similar functionality to REFPROP, but CoolProp is open-source and free. It was originally developed by Ian Bell, at the time a post-doc at the University of Liege, in Liege, Belgium.

• CoolProp has flexible licensing terms: Commercial - ok! Academic? - ok!

• For Python, get the latest release via pip install coolprop

• ... other binaries are available from SourceForge

• There is also a bleeding edge nightly build of the development version.

• The documentation is available for the latest release and the development version

• For any kind of question regarding CoolProp and its usage, you can ask the CoolProp Discussions

• ... you might also find answers in our FAQ

• If you found a bug or have an issue that requires the developers to become active, please file an issue in our issue tracker

• Contributions to this project are welcomed and encouraged! If you wish to contribute bug fixes, patches, or new features, wrappers, or material properties, please submit a Pull Request with your code.

• If you are new to Git and Github, please see the CoolProp Wiki for guidance on becoming a contributor to the project.

CMake package

CoolProp can build and install static and shared libraries independently or in the same build:

cmake -S . -B build \
  -DCOOLPROP_STATIC_LIBRARY=ON \
  -DCOOLPROP_SHARED_LIBRARY=ON
cmake --build build --config Release
cmake --install build --config Release --prefix /path/to/prefix

An installed package is consumed through imported targets, without manually adding include directories or platform libraries:

find_package(CoolProp 8 CONFIG REQUIRED)
target_link_libraries(my_app PRIVATE CoolProp::CoolProp)

When CoolProp is configured with both variants, the producer-side COOLPROP_DEFAULT_LIBRARY cache setting chooses which variant is exported through CoolProp::CoolProp (SHARED by default). This choice is recorded in the installed package and cannot be changed by a package consumer. Consumers that require explicit linkage should use CoolProp::Static or CoolProp::Shared. Separate consumer targets may select different variants, but one final binary must not link both variants. On Windows, the portable shared-library interface is the C API from CoolProp/CoolPropLib.h; use the static target for the complete C++ API.

Source-tree consumers can use the same canonical target:

set(COOLPROP_STATIC_LIBRARY ON CACHE BOOL "" FORCE)
add_subdirectory(externals/CoolProp)
target_link_libraries(my_app PRIVATE CoolProp::CoolProp)

Nested builds add no CoolProp install rules by default. A parent project that intentionally packages CoolProp can enable COOLPROP_INSTALL_CMAKE_PACKAGE and/or COOLPROP_INSTALL_LEGACY_LAYOUT before calling add_subdirectory.

By default, COOLPROP_VENDOR_THIRD_PARTY=ON bundles the pinned Eigen and fmt headers and licenses into the relocatable package. Their sources are fetched even with CPM_USE_LOCAL_PACKAGES=ON, because installed packages may not supply the source files required for vendoring. Explicit CPM_Eigen_SOURCE and CPM_fmt_SOURCE source-directory overrides remain supported; they must point at complete source trees, including the upstream license files. Distributors can set COOLPROP_VENDOR_THIRD_PARTY=OFF to use installed Eigen3 and fmt CMake packages instead (Eigen 3.4 or newer); downstream consumers must then provide those packages too. This option concerns Eigen/fmt only, not CoolProp's other build dependencies.

Use CMAKE_INSTALL_PREFIX (or cmake --install --prefix) to choose the install location. The legacy COOLPROP_INSTALL_PREFIX override must not be empty and is ignored in nested builds, which retain their parent's install prefix.

Sponsors

Free code signing on Windows provided by SignPath.io, certificate by SignPath Foundation.