[Equation of state limits]

[jowr]

[Equation of state limits]

[jowr]

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]

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]

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

[nkampy]

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 [email protected] 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]

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 [email protected] 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 [email protected]
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]

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