Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

REFPROP should not be reloaded after every call to PropsSI #431

Closed
ibell opened this issue Jan 27, 2015 · 9 comments
Closed

REFPROP should not be reloaded after every call to PropsSI #431

ibell opened this issue Jan 27, 2015 · 9 comments
Milestone

Comments

@ibell
Copy link
Contributor

ibell commented Jan 27, 2015

When PropsSI is called multiple times, REFPROP should not be reloaded for each one, it is much slower. What was the reason behind the destructor unloading REFPROP dll every time (https://github.com/CoolProp/CoolProp/blob/master/src/Backends/REFPROP/REFPROPMixtureBackend.cpp#L280-L303)? We could add a simple wrapper class of REFPROP (REFPROP manager) that will ensure that the REFPROP unloader gets called exactly one time when the last instance is unloaded.

This code:

import CoolProp

CoolProp.CoolProp.set_debug_level(10)
PropsSI = CoolProp.CoolProp.PropsSI

for i in range(4):
    PropsSI('T','P',101325,'Q',0,'REFPROP::Water')

yields

REFPROP error/warning [ierr: 101]: [SETUP error 101] error in opening file for component #  1; filename = (WATER
..\..\..\..\src\Backends\REFPROP\REFPROPMixtureBackend.cpp:419: Successfully loaded REFPROP fluid: WATER.FLD
_PropsSI will return 373.124
REFPROP error/warning [ierr: 101]: [SETUP error 101] error in opening file for component #  1; filename = (WATER
..\..\..\..\src\Backends\REFPROP\REFPROPMixtureBackend.cpp:419: Successfully loaded REFPROP fluid: WATER.FLD
_PropsSI will return 373.124
REFPROP error/warning [ierr: 101]: [SETUP error 101] error in opening file for component #  1; filename = (WATER
..\..\..\..\src\Backends\REFPROP\REFPROPMixtureBackend.cpp:419: Successfully loaded REFPROP fluid: WATER.FLD
_PropsSI will return 373.124
REFPROP error/warning [ierr: 101]: [SETUP error 101] error in opening file for component #  1; filename = (WATER
..\..\..\..\src\Backends\REFPROP\REFPROPMixtureBackend.cpp:419: Successfully loaded REFPROP fluid: WATER.FLD
_PropsSI will return 373.124
@ibell ibell added this to the v5.0.7 milestone Jan 27, 2015
@ibell
Copy link
Contributor Author

ibell commented Jan 27, 2015

So, the issues are:

  1. We want to tie one instance of REFPROP to a state class
  2. We want that multiple calls to PropsSI that use REFPROP do NOT result in REFPROP being loaded every time

@ibell
Copy link
Contributor Author

ibell commented Feb 2, 2015

@jowr I've been thinking about this quite a bit, and am at an impasse. What is the best way to go about this? Hold onto the last state class created using a shared_ptr, and only reset it if the fluid string changes?

@jowr
Copy link
Member

jowr commented Feb 3, 2015

Yes, that sounds like the easiest solution. I am not sure how much it takes to implement this, but I reckon that this is the "cheapest" solution for now.

@ibell
Copy link
Contributor Author

ibell commented Feb 3, 2015

Yet another idea, when the REFPROP class calls its destructor, store the
pointer to the REFPROP dll instance, and the fluids loaded as a string.
That REFPROP instance could be loaded in the next call to the constructor.
I gather that REFPROP does not reload the fluids if the fluids have not
changed, so there is no need to check that in the CoolProp code.

On Tue, Feb 3, 2015 at 3:18 AM, Jorrit Wronski notifications@github.com
wrote:

Yes, that sounds like the easiest solution. I am not sure how much it
takes to implement this, but I reckon that this is the "cheapest" solution
for now.


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

@ibell
Copy link
Contributor Author

ibell commented Feb 7, 2015

So some info:

@ibell
Copy link
Contributor Author

ibell commented Feb 7, 2015

@ibell
Copy link
Contributor Author

ibell commented Feb 7, 2015

@ibell
Copy link
Contributor Author

ibell commented Feb 10, 2015

We have a problem with master. This (windows, python27, x64) crashes, but not until returning the same critical temperature (that of nitrogen) for BOTH states !!!! Which is clearly wrong! For some reason the second nitrogen call causes a crash. The problem is that there is only one instance floating around, and the second instantiation calls setup and sets the variables internally.

import CoolProp

Water = CoolProp.AbstractState('REFPROP', 'WATER')
N2 = CoolProp.AbstractState('REFPROP', 'NITROGEN')
print Water.keyed_output(CoolProp.iT_critical), N2.keyed_output(CoolProp.iT_critical)

N2 = CoolProp.AbstractState('REFPROP', 'NITROGEN')
Water = CoolProp.AbstractState('REFPROP', 'WATER')
print Water.keyed_output(CoolProp.iT_critical), N2.keyed_output(CoolProp.iT_critical)

@ibell ibell closed this as completed in e8b02d4 Feb 10, 2015
@ibell
Copy link
Contributor Author

ibell commented Feb 10, 2015

Now this works properly:

import CoolProp

Water = CoolProp.AbstractState('REFPROP', 'WATER')
N2 = CoolProp.AbstractState('REFPROP', 'NITROGEN')
print Water.keyed_output(CoolProp.iT_critical), N2.keyed_output(CoolProp.iT_critical)

N2 = CoolProp.AbstractState('REFPROP', 'NITROGEN')
Water = CoolProp.AbstractState('REFPROP', 'WATER')
print Water.keyed_output(CoolProp.iT_critical), N2.keyed_output(CoolProp.iT_critical)

yields

647.096 126.192
647.096 126.192

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants