search

jowr / librefprop.so

Create a shared library from the Fortran sources provided by Refprop from NIST. This project provides an alternative to the refprop.dll that comes with the software. Please use the official instructions if possible
https://github.com/usnistgov/REFPROP-cmake
33 stars 8 forks source link

[Equation of state limits] #27

Closed tonkiplis closed 8 years ago

tonkiplis commented 9 years ago

Problem:

I was trying to increase the temperature limit of the transport equations (viscosity) from 1350.0 K to 2000.0 K (for water).

For the purpose, I followed the procedure from: NIST-LFAQ

In brief, I (1) opened the the WATER.FLD file and (2) modified the corresponding upper temperature limit under the banner #ETA. As the changes were accounted for in Refprop: Substance/Fluid Information as in Excel, the range was not increased for Matlab.

Interestingly, if I change the temperature limit of the #EOS, changes are taken into account in Refprop, Excel and Matlab. Therefore it is not a compilation issue but maybe Matlab reads the limit somewhere else... Does anybody have an idea how to solve this?

Have a nice day,

Tonkiplis

Systems:

Refprop v9.1 Windows 7 Matlab R2012a Excel 2010

and

Refprop v9.1 MAC OS X 10.8.5 Matlab R2011

jowr commented 9 years ago

Hi, do you use Windows or MacOS, does the same happen on both platforms? Could it be that the EOS limits get checked as well due to some calls in refprop.m? You might want to contact NIST about this. Please report back here if you got an answer.

tonkiplis commented 9 years ago

I can reproduce the problem on both platforms, this is how I came to the conclusion that it is not related to the compilation, where is it the most appropriate to contact them?

NIST- questions ?

jowr commented 9 years ago

Contact details are given at the bottom of http://www.boulder.nist.gov/div838/theory/refprop/Frequently_asked_questions.htm

nkampy commented 9 years ago

Tonkipils,

I've got some experience working with the "guts" of refprop. After reading Eric Lemmon's LFAQ, I would suggest that if you want to change transport properties you need to change FIRST the #EOS and THEN the #ETA. My understanding is that refprop first calculates the EOS for a given state and then calculates the required transport property. You can review the order of calculation in the refpropm.m file that you are calling. So in short when calling refprop from matlab you are using the refpropm.m version of the software (which decides how to call the library functions) and when calling it in excel, you are using a different method of calling the library functions. Likewise if you wrote code in C, C++ or fortran, you then specified the order to call the refprop functions.

You should feel free to contact Eric as you may have uncovered a bug in the specific way that you used the code. Just be super clear with him so it doesn't use up a lot of his time trying to figure out what your doing. IE find the simplest two cases on a windows system that illustrate the issue. Jowr is completely right in that this issue has nothing to do with lbrefprop but with the original program.

Hope that helps and wasn't too much detail.

Nate

On May 7, 2015, at 2:40 AM, Jorrit Wronski notifications@github.com wrote:

Contact details are given at the bottom of http://www.boulder.nist.gov/div838/theory/refprop/Frequently_asked_questions.htm

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

ibell commented 9 years ago

If you could CC me as well in your email to Eric, that would be great. I work at NIST with Eric as well. And I can try to debug.

On Thu, May 7, 2015 at 7:36 AM, nkampy notifications@github.com wrote:

Tonkipils,

I've got some experience working with the "guts" of refprop. After reading Eric Lemmon's LFAQ, I would suggest that if you want to change transport properties you need to change FIRST the #EOS and THEN the #ETA. My understanding is that refprop first calculates the EOS for a given state and then calculates the required transport property. You can review the order of calculation in the refpropm.m file that you are calling. So in short when calling refprop from matlab you are using the refpropm.m version of the software (which decides how to call the library functions) and when calling it in excel, you are using a different method of calling the library functions. Likewise if you wrote code in C, C++ or fortran, you then specified the order to call the refprop functions.

You should feel free to contact Eric as you may have uncovered a bug in the specific way that you used the code. Just be super clear with him so it doesn't use up a lot of his time trying to figure out what your doing. IE find the simplest two cases on a windows system that illustrate the issue. Jowr is completely right in that this issue has nothing to do with lbrefprop but with the original program.

Hope that helps and wasn't too much detail.

Nate

On May 7, 2015, at 2:40 AM, Jorrit Wronski notifications@github.com wrote:

Contact details are given at the bottom of http://www.boulder.nist.gov/div838/theory/refprop/Frequently_asked_questions.htm

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

— Reply to this email directly or view it on GitHub https://github.com/jowr/librefprop.so/issues/27#issuecomment-99867783.

jowr commented 8 years ago

OK, I recon this was a pure REFPROP issue. Close it for now.