Mac 64bit matlab integration
tconboy opened this issue · comments
Mac OSX 10.9.4, Matlab R2013b. Successfully integrated librefprop.dylib with python using the steps outlined here (thanks!)
When I try to perform the matlab integration, I run into this error in one of the manual intermediate steps. Unix terminal asks to edit 'refprop.m', then run 'thunk.m'.
This is the error for running thunk.m:
attempted to access out(0); index must be a positive integer or logical.
Error in loadlibrary>getLoadlibraryCompilerConfiguration (line 539)
if (strcmp(out(end), char(10)))
Error in loadlibrary (line 253)
[thunk_build_fn,preprocess_command]=getLoadlibraryCompilerConfiguration(ccinclude,header,headername,compilerConfiguration);
Error in thunk (line 2)
loadlibrary('librefprop','header.h','mfilename','rp_proto64')
Error in run (line 63)
evalin('caller', [script ';']);
Also, here is my gcc info:
gcc --version
Configured with: --prefix=/Library/Developer/CommandLineTools/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn)
Tconboy,
I apologize that I didn't get back to you sooner. Its hard for me to tell what went wrong for you if the following hint doesn't help you please fire back with more details. I think that at this step I had problems due to some file permission issues. If I remember right I used the chown command to change the owner from root to my user name for the files to be modified so that when I ran the sudo .... command to modify the file it would work. I too am running 10.9.4 and use refprop 9.1 with matlab R2014a all the time. If my hint is unclear, I can reinstall and write a step by step correction procedure. I haven't done this yet since I was working on changing the process to simplify things and hopefully avoid this issue. Just got bogged down with moving this summer for an internship with NIST. Please let us know how its working out for you.
Nate
On Jul 24, 2014, at 8:49 AM, Jean-Baptiste Carré notifications@github.com wrote:
Has the issue been solved @tconboy or are you still stuck at it? Unfortunately, @jowr or me doesn't have an Apple computer available currently to reproduce the problem, so, if you're still stuck with this error, we might need to ask for some external testers. Keep us tuned! ;-)
—
Reply to this email directly or view it on GitHub.
That is interesting. There should not be any problems with the permissions since the makefile sets them during installation or does https://github.com/jowr/librefprop.so/blob/master/Makefile#L185 need to be corrected?
Hi all, thanks for the concern and quick response. Since my original comment, I tried the installation again, and ran into the same problem. Everything goes well until the steps where I'm asked to manually edit the 'case' structure in refprop.m, which seems to work fine. But then, running thunk.m doesn't work. The 'thunk' file fails with the error above. I attempted to use the hint @nkampy provided regarding chown, but not sure if I implemented it correctly. Are there any other details that I could provide that might help diagnose this better? Unfortunately I'm not an experienced programmer, just a guy who wants to use refprop on a mac ;).
tconboy,
If the problem happened when you tried the run thunk.m step inside MatLab from this piece of code:
function fixpath64 {
cp rp_proto64.m rp_proto64.m.tmp
echo " "
echo " "
echo " 2) Open Matlab, and run :"
echo " "cd pwd;""
echo " "run('thunk.m');""
echo " proceed by pressing ENTER."
read dummy
mv rp_proto64.m rp_proto64.m.thunk
mv rp_proto64.m.tmp rp_proto64.m
unamestr=uname
if [[ "$unamestr" == 'Linux' ]]; then
sed -i.du 's/REFPRP64_thunk_pcwin64/librefprop_thunk_glnxa64/g' rp_proto64.m
elif [[ "$unamestr" == 'Darwin' ]]; then
sed -i.du 's/REFPRP64_thunk_pcwin64/librefprop_thunk_maci64/g' rp_proto64.m
fi
rm rp_proto64.m.du
}
The problem is that you have not configured MatLab properly in order to generate your own librefprop_thunk_maci64.dylib file and rp_ proto64 changes. You need to dig more into the readme file and go to the matlab links that I posted there. You specifically need to configure your copy of matlab to use MEX compilation (which honestly is a pain since matlab doesn't do a good job of keeping up with MAC Xcode versions and gcc versions in step. On the bright side there are ways to manually fix this that require a little in-depth work and possibly requesting help from MathWorks support if the methods in the two links don't apply or work for your version of MatLab and can't be readily adapted.
There is a plan B but its not proven and may not work at all. On the windows side, one of the volunteer contributors developed the thunk method for win64 machines and found that the thunk dll and rp_proto64.m files could be shared with the refpropm.m file and they are known to work on any win64 machine (well more correctly we haven't found a case where they didn't work, IE cause an error or crash).
This has never been tried before for Macs or for Linux machines to my knowledge. Its possible to work, work less efficiently or maybe crash your system with disastrous results (data loss or hardware damage in the extreme) since the thunk dylib is not in a higher level programing language, but machine code. Hardware or software differences could result in differences in what the code should be, how its interpreted and what the computer does if there is a misinterpretation. This is why we didn't just try and configure a set of these files for mac and a set for linux.
I would not try to "share" the thunk .so on linux for this reason, but who knows it may work on a mac. It may damage your system. That is your risk and your choice. I would try to configure matlab first. Its totally doable, just takes persistence.
I was in your shoes 2 years ago with just wanting to get REFPROP and MAC working with MatLab with little to no experience in resolving these types of issues with systems and code. I've learned a lot along the way and much better off for it.
Best of Luck!
@tconboy could you solve your issues? Can you provide some feedback to improve our documentation/instructions?
Hi Guys, I found some assistance with the issue and have tried copying over the files from my maverick OS to Lion. Then tried to get things to work. After fixing the symbolic pointers because they didn't copy over correctly, The final unresolved error is that a dynamically shared library file is missing and the ref prop dylib is looking for it in the gcc fortran compiler's install location. Do you guys know the right switch to add at compile time for the .dylib so that it is self contained?
refpropm('T','P',101.325,'Q',0,'water')
Error using loadlibrary (line 422)
There was an error loading the library "/opt/refprop/librefprop.dylib"
dlopen(/opt/refprop/librefprop.dylib, 6): Library not loaded:
/sw/lib/gcc4.8/lib/libgomp.1.dylib
Referenced from: /opt/refprop/librefprop.dylib
Reason: image not found
Error in refpropm (line 239)
[notfound,warnings]=loadlibrary(strcat(BasePath,dllName),prototype,'alias',libName);
Caused by:
Error using loaddefinedlibrary
dlopen(/opt/refprop/librefprop.dylib, 6): Library not loaded:
/sw/lib/gcc4.8/lib/libgomp.1.dylib
Referenced from: /opt/refprop/librefprop.dylib
Reason: image not found
Ok, so I should be a little more clear. by tried to get things to work, I mean copying over the compiled files and avoiding using mat labs built in mex compilers and the pain that it is to set them up. It looks like we have an issue with open mp library not being automatically included into the dylib. Short of finding a proper fix, one can install the correct version of gcc in the same place as me or one of you guys if you want to post the dylib files or create the folder and make a link to the install location on the local machine. A third option is to try and let someone compile the .dylib on there computer and then see if our precompiled thunk dylib works with it.
Hi. Good to hear that there is some progress. Did you try compiling without OpenMP support? There is a switch in the makefile (https://github.com/jowr/librefprop.so/blob/master/Makefile#L51) that we included because has been a lot of trouble with OpenMP earlier. Maybe you could give it a shot and report back if that was a successful...