Skip to content

Author: admin-joel

where files really are on thuban2: /var/share (But not so fast for /usr/share/astro/ !)

e.g.  /var/share/data/psrdata

and /var/share/home/jweisber
(note that when I first log in to thuban2, I go to a wrong  /home jweisber  )

–joel 20220804

(But not so fast for mirzam’s /usr/share/astro/ “real” location on thuban2:

when I did a “mount” command on mirzam on 20231231, I discovered that

/usr/share/astro/ on mirzam is really on thuban2’s /var/share/astro_centos7/    !  )

–joel 20231231

tl;dr:  this stems from our upgrade from centos6 to 7. The directory still occupying thuban’s
/var/share/astro/ is a carcass from centos6 days!

To edit much of IDL source incl say coyote: must be on thuban2 on root and centos7

Because mirzam was down tonight I used idl on canopus instead. In trying to run some idl galactic magnetic field idl programs on canopus, I kept hitting an obscure error on coyote’s cggreek routine which makes greek letters for plots.  Googling it I found that an idl 8.6.1 (as on canny) error prevented old cggreek from working.  (It worked ok forever on mirzy, which has I think idl 8.7)

So I installed the new cggreek from github to thuban2’s /var/share/astro/idleshare/coyote.  but this didn’t work!  why?  because i had to install it onto /var/share/astro_centos7/idleshare/coyote   Note because of access issues, one can not install directly onto /usr/share/astro on mirzy or canny, but must instead go to thuban2/var/share/astro_centos7/ as above (and see below).

by the way i used su cp etc etc on thuban 2 to overcome permission issues on canny or mirzy themselves, but prev post shows that su – on thuban2 might be easier

building python 2.7 & related stuff on astronet

Yuping:

references:

https://www.digitalocean.com/community/tutorials/how-to-set-up-python-2-7-6-and-3-3-3-on-centos-6-4

https://www.digitalocean.com/community/tutorials/common-python-tools-using-virtualenv-installing-with-pip-and-managing-packages

——————————————————–

I decided for now to install python 2.7 instead of python 3.0  because that’s what most astronomy python libraries are compatible with (e.g. psrchive). If someone wants to build python 3.0 just substitute the following 2.7.12 with 3.0.* and that should work. Note that I install it in /usr/local/ for each of the computers (i’m not sure what exactly willhappen if multiple hosts try to run the same python) so the following is repeated for each computer we have.

——————————————————

prereqs: make sure you do

sudo yum install tcl tcl-devel tk tk-devel

and check to make sure that all prereqs specified in

https://www.digitalocean.com/community/tutorials/common-python-tools-using-virtualenv-installing-with-pip-and-managing-packages

are satisfied.


install:

First download python from https://www.python.org/ and untar it

>xz -d Python-2.7.12.tar.xz

>tar -xvf Python-2.7.6.tar
>sudo cp -r Python-2.7.6 /usr/local/src/

now we can cd into /usr/local/src/Python-2.7.6 and run

>sudo ./configure --prefix=/usr/local
>sudo make

make will complain about not having the following

>Python build finished, but the necessary bits to build these modules were not found:
>bsddb185           dl                 imageop
>sunaudiodev

These four we can live without (see http://www.kelvinwong.ca/2010/08/02/python-2-7-on-dreamhost/) but if you are missing more than that, google it up.

Now do the following (altinstall is very important otherwise you are gonna break CentOS)

> sudo make altinstall

Now python should be built with executable under /usr/local/bin/python2.7


Now build pip which does package management and virtualenv which lets
you install python library without sudo-ing and makes complicated
dependencies easier to handle (see reference article 2)

 

First you need setuptool because pip depends on it

You can download it from https://pypi.python.org/packages/source/s/setuptools/, untar it and copy it over to /usr/local/src/

then do

> cd setuptools-1.4.2

> sudo /usr/local/bin/python2.7 setup.py install

then you download pip from https://bootstrap.pypa.io/get-pip.py into /usr/local/src/ and do

> sudo /usr/local/bin/python2.7 get-pip.py

and pip should be installed.

Finally you can do the following to get some common libraries installed:

> sudo /usr/local/bin/pip2.7 install numpy scipy matplotlib astropy ipython

you can do this on a single computer, go to some nfs mounted directory (e.g. your home directory) and do

> /usr/local/pip freeze > package_list.txt

which pipes the current installed packages to the file package_list.txt. Then you can hop (ssh) onto other computers and just do

> sudo /usr/local/bin/pip2.7 install -r package_list.txt

And done!

more to come on installing python libraries without being sudo.

When the IDL license manager halts for no good reason on canopus…

Updated by Bruce and Joel July 2019

So apparently the license manager for idl on canopus loses connection to the server from time to time and Bruce found out that the best way to deal with it was just to power cycle it. Yuping encountered the problem again today and tried the following and it worked.

sudo su – (puts one into root and bash shell – must have sudo privileges)

$ cd /usr/local/exelis/idl83

This is where the IDL installation is

$./bin/lmutil lmdown

This will kill all of the license managers.

$ps aux|grep lm

Make sure that all lm’s are killed

$ ./bin/lmgrd > lmgrd-201Y-MM-DD.log

imgrd starts the license managers.

This appears to fix the problem.

-Yuping

On 2016-05-26, joel found that the above did not quitre work without some help.  I had to first create the log file with a sudo touch filename command, and then CONCAT to the log file in the above sh command by adding a second > to the first one.

psrchive build notes

PSRCHIVE BUILD NOTES

This file is also located /usr/share/astro/psrhome/PsarchiveBuildNotes.txt
Yuping Huang
02/25/2016

psrchive is built under 64bit and with gfortran as the fortran compiler. Note that they require a 64bit gfortran compiled pgplot. I will start by building psrchive since it well build its dependencies automatically.

—–PSRCHIVE—————
Set $PSRHOME to /usr/share/astro/psrhome/ this is the directory for all the softwares.

Add $PSRHOME/bin to your $PATH variable

$ cd $PSRHOME

Unzip psrcat in the directory (psrcat available at http://www.atnf.csiro.au/people/pulsar/psrcat/download.html). Then add in .cshrc setenv PSRCAT_FILE $PSRHOME/psrcat/psrcat.db

$ mkdir src && cd src

$ git clone git://git.code.sf.net/p/psrchive/code psrchive

$ cd psrchive

$ ./bootstrap

$ ./configure –prefix=$PSRHOME F77=gfortran

Then psrchive will complain about not having required packages. It generetes csh scripts under packages for installation and we will use those

$ cd packages

$./pgplot.csh

Remember to add to .cshrc $PGPLOT_DIR and $PGPLOT_FONTS as the script suggests. In my case it is

setenv PGPLOT_DIR $PSRHOME/pgplot/

setenv PGPLOT_FONTS $PGPLOT_DIR/grfont.dat

You should also add $PGPLOT_DIR to your LD_LIBRARY_PATH in .cshrc.

$./fftw.csh

$./cfitsio.csh

$PSRHOME/x86_64-linux/src/cfitsioTake notes of where the cfitsio source is located. We will need it later. In my case it is under $PSRHOME/src/cfitsio

$source ~/.cshrc

this step validates the changes made to the environmental variables.

$./tempo2.csh

This will install tempo2 but likely pgplot will not be linked and henceforth this is not yet a fully functional tempo2. But it does have the components
that psrchive needs. The tempo2 linked with pgplot will be built seperately later.

You should set your $TEMPO2 variable to the tempo2 runtime directory. In my case it is $PSRHOME/tempo2

$ cd ..

This should bring you back to the psrchive folder where configure is located. Now rerun ./configure. It should not complain about fftw, cfitsio, tempo2 or pgplot

./configure –prefix=$PSRHOME F77=gfortran –with-cfitsio-dir=$PSRHOME/src/cfitsio

If you are still having trouble, look at http://psrchive.sourceforge.net/third/packages.shtml. When I did it it can find everything but cfitsio so I fed in the
–with-cfitsio-dir directory. Now we are ready to build it.

$ make

$ make check

$ make isntall

Done! the binaries should locate in $PSRHOME/bin . You should add it to your $PATH variable.

Login Hangs After CentOS/RedHat Kernel Update

June 15, 2015

A second incident of login getting hung after kernel update is found. The first incident was reported on Aug 2, 2014. As usual when users type in user name and password at the login window and hit login the login process gets frozen and cannot get to the desktop. It appeared to only affect tsch (using .cshrc) users.

The solution is to hit ctrl-c and then rm .history to get rid of the .history file. Note that if you do it from ssh, it might cause the host to reboot.

Canopus and Algol got updated over the weekend to kernel version 2.6.32-504.23.4.el6.x86_64. Hence it seems like it is only affecting these two hosts.

-Yuping & Bruce

compile pgplot in 32bits

Since we decided to compile the computing programs in 32 bits to ensure consistencies, pgplot should be compiled in 32 bit as well so that those programs can call it. The build notes are in

/usr/share/astro/psrchive/00READMECarleton

 

The compatibility libraries (with the yum commands) that I had to pull in (which Bruce had a copy):

yum install compat-libgfortran-41.i686
yum install libICE-devel.i686

yum install glibc-devel.i686

yum install zlibrary-devel.i686

yum install libpng-devel.i686

yum install xorg-x11-server-devel.i686

yum install compat-libstdc++-33.i686

yum install compat-libstdc++-296.i686

yum install libxcb-devel.i686

yum install libxcb-devel.i686

yum install zlib-devel.i686

yum install libX11-devel.i686

 

-Yuping

mingw64-pkg-config.x86_64

I installed mingw64-pkg-config.x86_64

It seems like it need to pull in its sister package e2fsprogs before compiling dump by typing in the /root/ directory

$ git clone git://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git

$./configure –enable-elf-shlibs

$ make

$ make check

$ make install

$ make install-libs

which puts the binary file in /usr/bin or /usr/local/…

then go to the dump source file, type

http://surf.ml.seikei.ac.jp/~nakano/dump-restore/dump-restore-mini-HOWTO.en.html

Compiling Old fortran programs(&link pgplot) on 64-bit system

This post is for the old fortran computing programs (except TEMPO)

The moral of the story to compile those old programs in 32-bit on the 64-bit machines, because I could not find any documentation online re how f77 compiles differently in 64-bit and 32-bit. However, we do know that programs compiled in 64 bit behave differently from those compiled in 32-bit (for example the size of some data type are different). Therefore, on the 64-bit machines we should force compile these old programs in 32-bit to ensure consistency. The steps are as follows.

1. Make sure that your $PGPLOT_DIR environmental variable points to /usr/share/astro/psrchive/pgplot_32bits

2. Look at the make file. Add “-m32” to FFLAGS (meaning force compile in 32 bit for fortran) and make sure that the f77 step says f77 $(FFLAGS)     in order that the FFLAGS be invoked.

Make sure that the LIBS line have all of the following especially $(PGPLOT_DIR)

LIBS = -L$(PGPLOT_DIR) -lpgplot -L/usr/X11R6/lib -lX11 -lpng

Then we should be fine

–Yuping

—————————————————————————-

Pulling in additional 32-bit compat library when the compiler complains about not having it:

Do a google search to see what packages provide those libraries (theoretically “yum provides filename” should work but I never succeed on our computer. Useful stuff is “yum search keyword” which search through the available packages. Always pick the package ending with i686 (which stands for 32-bit) and devel if available

for example I see -lz and google tells me zlib is what I need. I run “yum search zlib” and just pick the one with “devel” and “i686″(meaning 32 bit). So I will type “sudo yum install zlib-xxxx-devel-i686