search

jowr / librefprop.so

Create a shared library from the Fortran sources provided by Refprop from NIST. This project provides an alternative to the refprop.dll that comes with the software. Please use the official instructions if possible
https://github.com/usnistgov/REFPROP-cmake
33 stars 8 forks source link

Enable local installation without root access #15

Closed jowr closed 10 years ago

jowr commented 10 years ago

Edit the makefile to handle bot, a system-wide and a local installation. Useful for users working on machines without root access.

ghost commented 10 years ago

BTW, it's not necessary to follow exactly @nkampy's procedure in order to have the 64 bits modification to work ; notably, you can run trunk.m directly from the repo directory, without copying to the install folder, which avoids the chmod and to run matlab script in /usr ;-)

jowr commented 10 years ago

The makefile can be used without root privileges now. However, I do not understand the procedure involving thunk.m.

Could you, @nkampy and @speredenn, please agree on how to handle this and clarify the instructions? BTW, adding an export of LD_LIBRARY_PATH to a bash profile is not recommended... See also: http://www.cc.dtu.dk/?page_id=304

ghost commented 10 years ago

yeah @jowr, I write a set of instructions the way they work for me and keep you tuned for the root access first, then I will give a try to the no root access instructions.

ghost commented 10 years ago

The procedure, with root access, on a GNU/Linux 64 bits computer, with code at commit b847a93, is:

This is what should do the Makefile, I guess :-/ ; it would be great then to test that on OSX and GNU/Linux, from scratch. At least this exact procedure works on my own computer, step by step.

jowr commented 10 years ago

The new makefile and scripts from d135d0ed9d1c125af941dd5e8e3997ef96e1dba4 should improve the user experience. However, testing is needed. Especially for OSX and non-root users.

jowr commented 10 years ago

It works on 32bit Linux. @speredenn, could you test it on 64bit Linux? ...and @ibell, maybe you find the time to try it on your Mac...

ghost commented 10 years ago

The way I have tested your commit 93a0350:

I have one or two minor improvements and corrections to propose; I commit then directly in your master branch, as they are trivial changes. Thanks for the hard work! Integration could be better, but that's already fairly good :-).

ghost commented 10 years ago

Done with the trivial modifications, pushed in your master branch (63155aa and 8165eba).

ghost commented 10 years ago

@nkampy: could you test the above procedure with the jowr/master HEAD commit on your MacOS 64 bits setup and confirm that it works too? :-)

jowr commented 10 years ago

Thanks for the testing and the contribution. Just one comment: I included the download of the m files in the makefile. You should not have to download anything manually...

ghost commented 10 years ago

Oh right, I had skipped reading this part in the Makefile ; sorry. Great that the Makefile downloads the files directly!

nkampy commented 10 years ago

Ok guys, I've hit a wall in trying to install the new version on a mac. When installing as the root for make and sudo make install then if I run sudo make matlab I can't modify refpropm.m in matlab or in Xcode.

Second, from a clean download, make and sudo make install then trying make matlab things bugger up at step two as the files aren't copies over to the documents/matlab folder.

Third, in the directions when running the fix files.sh script it may help to avoid confusion to be clear that the matlab folder in question is not the documents/matlab but the download location ..../librefprop.so-master/matlab location.

jowr commented 10 years ago

OK, I separated file handling and installation and updated the instructions to point to the correct matlab folder. Please try the following:

I hope that works for you. I have not been able to test it...

jowr commented 10 years ago

There are still some rough edges, but I think I got quite far. You might have to copy the dylib manually after you ran make matlab...

nkampy commented 10 years ago

Jowr, Your doing great! You guys have pulled off some pretty impressive stuff. Here is a run down of additional steps that I had to take to get your method to work on my mac (sudo make matlab): before step 1

At this point the test code runs just fine from the librefprop.so-master/matlab folder

I would recommend the script automatically move refpropm.m, rp_proto64.m and librefprop_thunk_maci64.dylib to opt/refprop. Then inform the end user to add the path opt/refprop to the matlab path.

Then any matlab script can call the ref prop method from anywhere on the computer.

Let me know what you guys think about the email I sent to NIST with the recommended changes. I'm hoping this makes things easy to install in the future and secondly make the methods available for less advanced users who can't get mex working with matlab.

ibell commented 10 years ago

Just an FYI, I'm going to be working at NIST starting in January. Can you forward me the email you sent to NIST to ian.h.bell .at. gmail.com ?

On Tue, Apr 29, 2014 at 9:41 PM, nkampy notifications@github.com wrote:

Jowr, Your doing great! You guys have pulled off some pretty impressive stuff. Here is a run down of additional steps that I had to take to get your method to work on my mac (sudo make matlab): before step 1

  • sudo chown USERNAME:wheel refpropm.m before step 2
  • sudo chown USERNAME:wheel rp_proto64.m after
  • copy the thunk.dylib to the refprop install folder opt/refprop

At this point the test code runs just fine from the librefprop.so-master/matlab folder

I would recommend the script automatically move refpropm.m, rp_proto64.m and librefprop_thunk_maci64.dylib to opt/refprop. Then inform the end user to add the path opt/refprop to the matlab path.

Then any matlab script can call the ref prop method from anywhere on the computer.

Let me know what you guys think about the email I sent to NIST with the recommended changes. I'm hoping this makes things easy to install in the future and secondly make the methods available for less advanced users who can't get mex working with matlab.

— Reply to this email directly or view it on GitHubhttps://github.com/jowr/librefprop.so/issues/15#issuecomment-41722447 .

nkampy commented 10 years ago

ibell, Congrats! what group are you going to? The long and short of the email was 3 suggested changes to how refprop is integrated into matlab. 1- expanding the switch case by computer return type in matlab. 2 - removing the BasePath input argument from the prototype file which as far as I can tell is an aftermarket modification that complicates the porting process. both of these will simplify the install process. 3 - propose a uniform naming convention for the dynamically shared library functions to enable a single make file for all platforms including windows, mac and linux without having to rename things to lower case for unix systems. (IE for librefprop.so to match the original refprop names) This would increase code portability across platforms.

nkampy commented 10 years ago

@jowr dug through the new parts of the make file and realized I wasn't following your directions to run make matlab-install after. Found an issue and repaired it. Just not sure how to code up the chown fix for the make matlab problem.

jowr commented 10 years ago

@nkampy, you should not need to chown the files. The script downloads them as normal user, then you edit them as normal user and eventually matlab-install copies them as root user and fixes permissions so everyone on the system can read/execute them. Are you sure they have to be chowned?

jowr commented 10 years ago

I just tested it and it works without any "chowning". Please report any issues. Installation should be similar on all Macs if there is a difference between @nkampy's machine and mine, we need to find out what is going on.

jowr commented 10 years ago

Can we consider this done? @nkampy does it work for you without changing file ownership?

nkampy commented 10 years ago

My last attempt required using chown. Not sure why. I used the sudo command. Is it possible my sudo does something different than your sudo command?

On May 5, 2014, at 11:40 AM, Jorrit Wronski notifications@github.com wrote:

Can we consider this done? @nkampy does it work for you without changing file ownership?

— Reply to this email directly or view it on GitHub.

jowr commented 10 years ago

No. I do not think so. But it is important to start from a clean directory. If you ran a command with sudo that should not be run as root, you might end up with files having the wrong permissions... That is why I recommend the cleaning procedure earlier in this thread:

However, the safest way is to clone the whole project again to anew directory.

nkampy commented 10 years ago

Starting from a clean install, It works. It would be nice to verify with another tho as it seemed to be glitchy, but I couldn't quite figure out why. Also, I would change the cp commands to mv for refpropm.m and .dylib as multiple copies of the proto64 file can cause problems.

Ok, now that this stage is pretty well rounded out. We could try the next level of simplicity for installing the matlab interface. It is possible to bypass the mex compilation required portions of the process by providing the end user with the thunk.dylib, rp_proto files that go with it based on what system they have. These files are meant to be cross computer compatible for the same platform. IE any red hat linux 64 bit machine can use the same exact files as another without compiling the code over again. (Binaries) This might put the code into the hands of people who cant get the mex functionality in matlab working.

On May 5, 2014, at 2:25 PM, Jorrit Wronski notifications@github.com wrote:

No. I do not think so. But it is important to start from a clean directory. If you ran a command with sudo that should not be run as root, you might end up with files having the wrong permissions... That is why I recommend the cleaning procedure earlier in this thread:

Run sudo make uninstall clean to remove the fortran files and sudo rm matlab/*.m.org to clean the matlab files. Run make and then sudo make install to install the shared library. Run make matlab to download files and edit them as written in the terminal. Run sudo make matlab-install to copy the matlab file to /opt/refprop. However, the safest way is to clone the whole project again to anew directory.

— Reply to this email directly or view it on GitHub.

ghost commented 10 years ago

@nkampy I disagree ; I've experienced that, depending on your GNU/Linux or OSX version + depending on your MATLAB version, the mex file was not working and needed to be recompiled for the specific computer, over time (and I've needed this procedure many many times). So I disagree that it could be a good idea to provide something which has been compiled thanks to the shitty MATLAB ways ;-). I would recommend to keep the things being done by the users, when they get the code. Moreover, it is a bad idea to keep binaries in a git repository while you could just compile them from the code ;-).

jowr commented 10 years ago

I'll change the cp to mv.

Thank you all for the contributions! I hope that we can get Eric to change the .m files in the NIST FAQ, this will make the installation much easier. I agree that the compilation can be left to the users. However, we can discuss other options to make even less complicated. For now, I will release the next version since I consider support of 64bit Linux and Mac a big improvement! Thanks again for sharing your experience, both of you.