Schrodinger Suite (supported on Red Hat not on Arch Linux)

gzSupertramp · 2017-10-01 18:50:19

I am currently setting up an Arch workstation for molecular computations: Schrodinger Suite software (Maestro + especially MacroModel).

Officialy supported distros: Red Hat/Ubuntu but not Arch Linux.

I managed to make the main software (Maestro) start and it seems to work fine.

The problem arises when I try to compute something: minimization calculations for ex. This is the job of the MacroModel software.

For some reason I keep getting a command error: "NaN is not a real value for. ... ". This occurs on two different computers running arch linux (one with Xeon processors and another one with an i7 4790K).

Note: the software uses python
Note: I had to downgrade the libpng package in order to make Maestro start

What could Red Hat/Ubuntu have that Arch linux does not? Why would a software run on Red Hat and not Arch?

Thank you for your support!

Last edited by gzSupertramp (2017-10-01 20:28:00)

yodermk · 2017-10-01 19:59:10

Maybe depends on a specific older version of some Python module like numpy or pandas or scipy? If so it should be possible to run in a virtualenv.

Does it only support RHEL/Ubuntu LTS or the Fedora and the latest Ubuntu?

You might talk to the software's authors about any specific needs. I can't imagine that Arch would be inherently incapable of running it.

gzSupertramp · 2017-10-01 20:23:32

yodermk wrote:

Maybe depends on a specific older version of some Python module like numpy or pandas or scipy? If so it should be possible to run in a virtualenv.
Does it only support RHEL/Ubuntu LTS or the Fedora and the latest Ubuntu?
You might talk to the software's authors about any specific needs. I can't imagine that Arch would be inherently incapable of running it.

First of all. Thank you for your answer.

It supports also CentOS and SUSE; Windows and Mac.

You might be on the right road: I will look into it (I sent already an email to the software support.. awaiting for their reply.)

Can't I just install those packages without using a virtualenv?

Last edited by gzSupertramp (2017-10-01 20:38:10)

Durden · 2017-10-01 21:00:33

Depends. Red Hats base system is positively ancient. Arch is very fresh as you can tell. Red Hat still uses Python 2 as default while Arch is using Python 3.6. Many other differences in libraries. The differences will run very deep, especially since Red Hat does a lot of modifications to their base packages.

If they distributed the suite via Docker or Flatpak then it would be less of an issue as they could package dependancies with it. Is the software 32 or 64 bit by chance? If 32 bit you may need to pull in libraries from multilib repo.

Durden · 2017-10-01 21:06:34

BTW, there is a program called flatpak-builder, (http://docs.flatpak.org/en/latest/flatpak-builder.html) which might help. You may be able to package the suite your self as a flatpak application and check it into a local git repo. Learning curve with this but you might find it worthwhile.

More info on Flatpak
https://wiki.archlinux.org/index.php/Flatpak
http://flatpak.org/
https://www.flathub.org/

jsoy9pQbYVNu5nfU · 2017-10-01 21:18:20

Best option: use systemd-nspawn to bootstrap and launch a CentOS 7 system, then install your application suite in that container.

You can actually configure programs running in containers/separated namespaces as created by systemd-nspawn to use the host's Xorg server for displaying stuff.

This solution would allow you to have a stable computing environment with the applications actually running in the environment they were created for and tested in – always good for productivity.

progandy · 2017-10-01 21:38:50

Can't I just install those packages without using a virtualenv?

That is not a good idea. All arch packages are always compiled for the dependencies in the repositories. If you install something older to support one application, you are likely to break everything else that depends on the newer library. Even downgrading libpng is not too good. Maybe it would be possible to install the older version in parallel to the new one or you should put it in a different directory and use LD_LIBRARY_PATH.

By the way, these are the supported systems. As 2ion said, running a systemd-nspawn or chroot container would be the most reliable setup, but flatpak works too.

https://www.schrodinger.com/supportedplatforms
All applications are 64-bit versions only. All supported distributions have a glibc of 2.5 or greater.
Supported
RedHat Enterprise Linux (RHEL) 6.7-6.9, 7.2-7.3
For RHEL Server you must install some X11 libraries (sudo yum install fontconfig libX11).
CentOS 6.7-6.9, 7.2-7.3
For CentOS Server you must install some X11 libraries (sudo yum install fontconfig libX11).
Ubuntu 14.04 LTS, and 16.04 LTS
For Ubuntu Server, user must also install some X11 libraries (sudo apt-get install fontconfig).
SUSE: SLES 12 SP2, SLED 12 SP2

Last edited by progandy (2017-10-01 21:39:20)

Slithery · 2017-10-01 22:45:50

Personally I'd use a Ubuntu 16.04 installation instead of CentOS for the container as it easily created by the debootstrap script...
https://wiki.archlinux.org/index.php/Sy … nvironment

gzSupertramp · 2017-10-02 04:53:34

Thank you guys for all the input you are giving me!

I am looking into all of your suggestions.

Question:

if I have to run another Distro from a container with systemd-nspawn, isn't just better performance wise to just run a Red Hat/CetnOS/Ubuntu distro instead of Arch?

I would love to stick with Arch but if this will affect performance due to poor compatibility with the software suite then I would rather use another Distro (this workstation will be used my several users at work).

Last edited by gzSupertramp (2017-10-02 04:53:54)

gzSupertramp · 2017-10-02 04:54:46

progandy wrote:

Can't I just install those packages without using a virtualenv?
That is not a good idea. All arch packages are always compiled for the dependencies in the repositories. If you install something older to support one application, you are likely to break everything else that depends on the newer library. Even downgrading libpng is not too good. Maybe it would be possible to install the older version in parallel to the new one or you should put it in a different directory and use LD_LIBRARY_PATH.
By the way, these are the supported systems. As 2ion said, running a systemd-nspawn or chroot container would be the most reliable setup, but flatpak works too.
https://www.schrodinger.com/supportedplatforms
All applications are 64-bit versions only. All supported distributions have a glibc of 2.5 or greater.
Supported
RedHat Enterprise Linux (RHEL) 6.7-6.9, 7.2-7.3
For RHEL Server you must install some X11 libraries (sudo yum install fontconfig libX11).
CentOS 6.7-6.9, 7.2-7.3
For CentOS Server you must install some X11 libraries (sudo yum install fontconfig libX11).
Ubuntu 14.04 LTS, and 16.04 LTS
For Ubuntu Server, user must also install some X11 libraries (sudo apt-get install fontconfig).
SUSE: SLES 12 SP2, SLED 12 SP2

Good Point!

progandy · 2017-10-02 16:10:29

gzSupertramp wrote:

if I have to run another Distro from a container with systemd-nspawn, isn't just better performance wise to just run a Red Hat/CetnOS/Ubuntu distro instead of Arch?

I am not too familiar with systemd-nspawn, that might result in a bit of a performance hit, but not as severe as a virtual machine.

Last edited by progandy (2017-10-02 16:14:09)

Durden · 2017-10-02 16:22:49

Performancewise Flatpak will probably be your best bet as it wont require running an entire distro in a container. I find flatpak apps slightly slower on startup but otherwise no real difference in performance.

Running a systemd-nspawn is a great idea and I don't want to poo poo it, I just don't think it's as easy or as flexible. For example, if you create the flatpak it'll be portable to any other system with minimal effort. You just add the local repo and run the flatpak.

I'm actually not a fan of flatpak for my personal use but it was designed specifically for what you're trying to do. Its a truly portable format. Another option which might be easier too is Appimage https://appimage.org/

Appimage might be even easier and definitely even more portable, I just have less experience with it so can't give much advice there.

gzSupertramp · 2017-10-10 06:52:04

So, I have been in contact with the Software support and they suggested me to install a new version of the software: it fixed the main problem.

Now I have a new one:

the software only seems to work with older versions of the libpng package (1.6.28 or older): downgrading the libpng to this version fixes all issues.

Could you guys give me specific instructions on how to tell the Schrodinger software to use the old one? I have extracted the old one into /opt/libpngOld

I usually run the software with the following command:

 $SCHRODINGER/maestro -NOSGL

where SCHRODINGER= /opt/schrodinger2017-3 defined in /etc/enviroment

I know it has something to do with setting LD_LIBRARY_PATH but I am not sure where I should do that

Thank you

progandy · 2017-10-10 09:14:47

LD_LIBRARY_PATH is an environment variable you can set, but do so only for specific applications and not in your shell startup (e.g. bashrc). It gives additional paths to search for libraries before looking in the normal directories.

env LD_LIBRARY_PATH=/opt/libpngOld /your/app --some_param

You could also try to change the rpath of maestro. It is similar to LD_LIBRARY_PATH, but the path is then stored inside the binary and you don't have to specify each time you start it.
http://jlk.fjfi.cvut.cz/arch/manpages/man/patchelf.1

Last edited by progandy (2017-10-10 09:18:49)

Arch Linux

#1 2017-10-01 18:50:19

Schrodinger Suite (supported on Red Hat not on Arch Linux)

#2 2017-10-01 19:59:10

Re: Schrodinger Suite (supported on Red Hat not on Arch Linux)

#3 2017-10-01 20:23:32

Re: Schrodinger Suite (supported on Red Hat not on Arch Linux)

#4 2017-10-01 21:00:33

Re: Schrodinger Suite (supported on Red Hat not on Arch Linux)

#5 2017-10-01 21:06:34

Re: Schrodinger Suite (supported on Red Hat not on Arch Linux)

#6 2017-10-01 21:18:20

Re: Schrodinger Suite (supported on Red Hat not on Arch Linux)

#7 2017-10-01 21:38:50

Re: Schrodinger Suite (supported on Red Hat not on Arch Linux)

#8 2017-10-01 22:45:50

Re: Schrodinger Suite (supported on Red Hat not on Arch Linux)

#9 2017-10-02 04:53:34

Re: Schrodinger Suite (supported on Red Hat not on Arch Linux)

#10 2017-10-02 04:54:46

Re: Schrodinger Suite (supported on Red Hat not on Arch Linux)

#11 2017-10-02 16:10:29

Re: Schrodinger Suite (supported on Red Hat not on Arch Linux)

#12 2017-10-02 16:22:49

Re: Schrodinger Suite (supported on Red Hat not on Arch Linux)

#13 2017-10-10 06:52:04

Re: Schrodinger Suite (supported on Red Hat not on Arch Linux)

#14 2017-10-10 09:14:47

Re: Schrodinger Suite (supported on Red Hat not on Arch Linux)

Board footer