MATLAB 64 bit Does not work

[jowr]

MATLAB 64 bit Does not work

[jowr]

Hi, sounds like you already have an idea about what is going wrong. Unfortunately, I do not have access to a Mac and my Linux box runs 32 bit, so I guess I cannot really assist you. Please keep me updated and share the solution in case you get that far ;-) .

[nkampy]

Will do, got some source code for generating the proto_64.m file from the author that shared it with Eric Lemmon at NIST. Attempting to get it to work correctly on a win 64 bit machine and then will try to adapt it to your Mac / linux method.

[jowr]

That sounds great. Thanks for your help!

I get the same troubles using librefprop.so with a GNU/Linux 64 bits MATLAB (R2013a). I get this MATLAB error for any refpropm command I try:

Error using calllib
Too many inputs passed to SimpleFunctionThunk.

Error in refpropm (line 253)
        [nc path hmix href ierr errTxt] =
        calllib(libName,'setupdll_',numComponents,path,hmix,href,0,32*ones(255,1),10000,255,3,255);

@nkampy could you please share some of the details Eric and the thunk dll guy gave you? I'm interested in having this issue solved fast ^_^ ;

[nkampy]

Speredenn,

I would love to have this problem solved, but its a bit sticky. In short, the way that REFPROPm.m is written is not recommended by Matlab and it results in Jowr's method of rewriting the files rather than using the load library command to regenerate them with matlab. This works great for 32 bit versions as they don't require the additional 64 bit thunk dynamically shared library file in addition to the REPROP library. Specifically, the protofile generated when using the load library command lacks a basePath input argument. You need to use the load library command to generate a thunk.so in your linux 64 bit case. This will also generate a protofile which then needs to be discarded in favor of the converted 64 bit one from jowl's method. To get the load library command to work you must check the compiler compatibility chart on math works and install supported compilers then configure them with mex -setup, then the load library command should work. I'm stuck at getting the right versions of matlab, operating system, Xcode (mac case) and compilers all at the same time. Then the above process should work for me on a mac. Once I finish or give up on the mac side i'll duplicate it for linux. If you send me a private message with your direct email, I'll be happy to share the files. Hopefully, I'll have the method working on Mac or unix very soon, but don't hold your breath, getting the mex file / load library method to work right can be a real pain. btw I'm now running OS X 10.9.2 with R2014a and will be trying the method on a linux super computer with red hat enterprise and matlab R2013a or R2014a depending on when they upgrade.

[jowr]

I keep my fingers crossed for you. Unfortunately, I am running 32bit only and cannot really help with anything...

[nkampy]

Here is a little update. I've got REFPROP working on Maverick and RedHat 5 Enterprise. I also have MatLab's mex working on both. The problem is using the loadlibrary command within the mex capability to to build the thunk dynamically shared library. Its two different problems one for each operating system. I've got posts on the Mathworks website. Feel free to check them out and contribute if you can.

http://www.mathworks.com/matlabcentral/answers/125310-linux-redhat-5-enterprise-r2013a-loadlibrary-error

http://www.mathworks.com/matlabcentral/answers/125301-maverick-r2014a-loadlibrary-error-loaddefinedlibrary

[nkampy]

Ok, here is an update.
It looks like things are 99% there getting up and running on Mac OSX 10.9.2 with matlab 2014a student version. I'll trying and tidy up my on the fly code adjustments into a comprehensible followable format. Right now, I'm hoping that things are not far behind on the linux machine side as well.
T=refpropm('T','C',0,' ',0,'water')
Warning: The function 'SATSPLNdll' was not found in the library

In loadlibrary at 406
In refpropm at 226
T = 647.0960

[nkampy]

Got up and running with no errors on mac and linux. Its a bit complicated to combine the two methods as one is on a supercomputer where I don't have root access. Should I post two sets of files and directions?

[jowr]

Yes, please. I will be glad to help structuring your work. I really appreciate that you share your efforts since 64bit applications are more and more important and this perspective is missing completely until now. I am sure that @speredenn also can contribute. It looks like he also uses some sort of supercomputer...

Yeah, sure :-) I can fetch or pull your proposal in my own fork and help structuring the building process for 64 bits computers - I have a root access on at least one 64 bits GNU/Linux computer and can test the process on GNU/Linux super-computers too. Thanks to have reached a solution, @nkampy ; on my side, I'm still stuck on unsuccessful stuffs, as I couldn't invest much time in making lots of efforts on those points lately :-(.

[nkampy]

Ok, so my newbieness is showing a bit. I tried to fork, clone, commit and push my changes for the maci64 install, but it does not seem to be working correctly? not sure.....

[nkampy]

Ok, its now up. Hope you guys find this helpful and useful. I apologize if making a fork and then a branch off the fork was not the right way to upload the two sets of changes.....

@nkampy ; perfect for me the way you did it ; I've fetched your branch, and I try your work tomorrow. I'll keep you tuned with the results. Thank you again for the hard work.

I think it would be a good thing to centralize all the PATH changes in the makefile, in order to have then set once and for all (then the makefile would change the strings in the FORTRAN sources, in the MATLAB files, and in the bash scripts). For the same reason, I think that fixfiles.sh should be run directly from the makefile (make matlab, or something like that). I'll try to propose something after I have check that it works too on my 64 bits platforms.

[nkampy]

@speredenn I agree, Honestly I'm not that much of a programer.... just stubborn on getting my research accomplished. I was hoping you more code savy types could wip up some organization to code flow. I thought this would be best for someone who has access to both linux with and without root access as well as a mac for testing. btw I think your problem with be resolved when you use my method. It is how ever likely that it will uncover some of the errors I did with matlab linked above. MEX is a major pain to use especially on a mac. In the end, I'm hoping we can share this method with Eric Lemmon and see if the next release can't include a make file that works on all platforms. I know that is a big step up from what has been built here.

@nkampy : Sure! I'm a hobbyist programmer too, so no worry ;-). Your modifications are really interesting and it would be nice to have the choice between root access and no root access, I do agree. I'm also used to MATLAB mex files problems, which are just all so common when you start getting into mex files systems. Personally, I tend to offer a script that relink the system libs on MATLAB libs to the admin of the GNU/Linux or MacOS computers, but I'll have to figure out if that's appropriate here: I make the tests and come back :-)

I confirm it works with your method, @nkampy ; I try now to integrate the procedure that you describe in the readme file in the makefile as a 'make matlab' command. As it is now, your code will work only for 64 bits platforms and needs more integration with the @jowr's code. I try to propose something soon.

[jowr]

Great, let me know if I can help. I can offer you to do the integration with the makefile, but if you could provide a starting point, that would be very much appreciated.

OK, I let's do that. I come back with some code later on.

@jowr, could you confirm that the command 'uname -m' gives 'x86' as the returned string on your 32 bits computer? On my 64 bits GNU/Linux, it returns 'x86_64'. I want to use that in fixfiles.sh to activate one procedure or the other.

[jowr]

Output is slightly different: $ uname -m returns i686 on my Debian testing system.

[jowr]

So you are rewriting the fixfiles.sh? I will try to make separate issues for all the things that I would like to see changed. Please add missing information and assign yourself to what you are working on. Let us try to avoid conflicts...

OK, sorry ; my fixfiles.sh is almost ready, it lacks file existence testing then I can commit it ; sorry if we overlapped :-( ; I was needing a proper fixfiles.sh to call it from the makefile, that's why.

[jowr]

No worries. I am very happy that you guys contribute! I added both of you as collaborators. You have write access to the git repo.

[nkampy]

Wow, I drop out of the loop for a few days to go camping for my and my wife's birthdays this weekend and you guys go crazy! Thanks for all your work. $ uname -m returns 'x86_64' on both the super computer and my mac.

Yeah, the tests should be working, now :-). Give the new Makefile a try ;-). Thanks again @jowr for the integration :-).