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

Remap CoolPropDbl to double permanently #931

Closed
ibell opened this issue Jan 17, 2016 · 3 comments · Fixed by #953
Closed

Remap CoolPropDbl to double permanently #931

ibell opened this issue Jan 17, 2016 · 3 comments · Fixed by #953
Milestone

Comments

@ibell
Copy link
Contributor

ibell commented Jan 17, 2016

@jowr @mikekaganski ,

I am thinking of removing all the long double functions everywhere and bring everything to just use doubles. It would be a rather major change internally. But I think it would make the code quite a bit faster since the compiler can use the intrinsics better. Also, I find it extremely confusing to have some functions that want std::vector<double> and others that want std::vector<long double>.

What do you guys think?

@jowr
Copy link
Member

jowr commented Jan 18, 2016

Go for it. I have not had any problems with truncation. 👍

@ibell
Copy link
Contributor Author

ibell commented Jan 19, 2016

I know this is going to be an issue with VLE calculations with water due to
the complexity of its EOS. I think a bit of testing would be appropriate
before committing this change.

On Mon, Jan 18, 2016 at 1:56 AM, Jorrit Wronski notifications@github.com
wrote:

Go for it. I have not had any problems with truncation. [image: 👍]


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

ibell added a commit that referenced this issue Jan 19, 2016
@ibell ibell added this to the v5.1.3 milestone Feb 1, 2016
@ibell
Copy link
Contributor Author

ibell commented Feb 2, 2016

I think this is going to happen. I made the necessary changes in the CoolPropDbl_to_double branch. There's a single macro that changes this behavior, and a single typedef in python land. The only problems I have seen in the tests are a few composition derivatives not quite getting to tolerance. Overall this seems like a safe change.

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

Successfully merging a pull request may close this issue.

2 participants