Has CoolProp been utilized interfacing codes that utilize GPUs?

[carlos23monteiro]

Hi,

As part of our research project we are utilizing an OOP C++ code that solves compressible turbulent flows with real-fluid thermodynamics. Instead of relying on the Peng-Robinson thermodynamic model we are about to start exploring the option of intergrating CoolProp. A code that successfully does this is SU2. In our case we utilize OpenACC to make our code GPU-enabled, which doesn't seem to tolerate the class dependencies in CoolProp.

My question would be if has anyone successfully ported to GPU or interfaced it to some hybrid code?

I would appreciate any feedback! Thank you in advance.

Best,
Carlos

[ibell]

Hi Carlos, CoolProp currently has no implementations/optimizations for GPU. To know more about how hard it would be, need to know more about what inputs and outputs you want.

[carlosabmonteiro23]

Hi Ian,

In most cases, the inputs are temperature and pressure. The outputs are typically density, internal energy, c_p, c_v, mu, kappa, speed of sound, volume expansivity, compressibilities, etc. There is an exception for 1 function in which the input is density and internal energy and the output is pressure and temperature. The idea is to incorporate CoolProp's functions directly in our kernels related to these thermodynamics calculations. At the moment, these utilize OpenACC to translate them into GPU code. In that sense OpenACC does not allow for dynamically allocated arrays or kernels, or nested/complex class dependencies. I guess this could present an obstacle.

What are your thoughts on this? Do you think that potential modifications to Coolprop focusing on the tabular approach could do the trick (as it conceptually may make more sense on GPU)?

Thank you in advance for your time. We are hoping to discuss it further.

Best,
Carlos

[ibell]

I am in the middle of writing a new tabular backend, based on some concepts from the SBTL method as well as some new ideas (the use of SVD to reduce data storage requirements). I asked claude about what the tradeoff is with this new code. The SVD evaluation is perfectly well-suited to GPU evaluation, but there is still a non-zero cost to moving the data to and from the GPU. It only makes sense if you are doing very large calculations in parallel. In that case you can see hundreds of times speedup relative to the CPU code, which is already VERY fast (order of 100 ns/call per property output).

[carlosabmonteiro23]

Hi Ian.

Sorry for the late reply. We have been debating this topic internally and we are also exploring this approach. The host-device movement cost is not an issue as this would be only done at the beginning and end of respective simulations. However, the SVD approach still yields some limitations close to the pseudo-boiling region and specially near the critical point. In that scenario, we would still have to refine around those thermophysical conditions, which brings back the issue of GPU memory, as these regimes are of particular interest to us. In parallel, we are experimenting with training a modular surrogate model with data from Cool-prop, outputting weights that will feed a thermodynamics machine learning algorithm, which would be more GPU-friendly and appears to yield very reasonably low levels of errors so far. We will keep exploring both approaches. Let me know if you would like to iterate on this, collaborating, or if we could be involved in any sense.

Best,
Carlos

[ibell]

Can you sketch out the portion of the phase diagram that is of interest to you? If the extended critical region in particular, that is ALWAYS going to be tricky. Whether a SVD-based method or anything else. Aside: SVD maps super nicely to GPU, so if you can find a reasonable solution there, should be able to make it very very fast. P,T inputs are easier because the phase diagram looks "normal" in these coordinates and you can map it more easily. D,U is very not straightforward. That is on my list for SVDSBTL, but will likely not land before v8 is released.