[Equation of state limits]
tonkiplis opened this issue · comments
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
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.
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?
Contact details are given at the bottom of http://www.boulder.nist.gov/div838/theory/refprop/Frequently_asked_questions.htm
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.
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
#27 (comment).
OK, I recon this was a pure REFPROP issue. Close it for now.