Skip to content

Category: Configuration

fixing problems with pgplot and cpgplot: building them and linking them to our own pgms

Published by jweisber on 2017-01-22

See updates at bottom from building pgplot and cpgplot on phasshare virtual 64 bit machine

First, recall that there is a pgplot-32bits (obsolete as of 2021 Feb ) and a pgplot (now 64) directory

On Aug 2, 2016, Yuping suggested putting cpgplot.h into /usr/include  .  Note this is NOT a shared directory so will need to be done on whatever host one is working on. If it is not there and one tries to build cpgplot, it will fail.

Another possible problem could occur when trying to link pgplot or cpgplot to a program.

e.g; the (64 bit) linking command

gfortran -o LKBorig LKBorig.o -L/usr/share/astro/psrhome/pgplot -lpgplot -lcpgplot -L/usr/lib64 -lX11 -lm -lstdc++ -lpng -lz

(cpgplot is just a c wrapper for pgplot and Yuping says it was actually pgplot that was damaged or missing.) (But see below 2021 Feb 3 update for a related prob- there we need to type ‘make cpg’  to make libcpgplot.a   . I dont think we use lib….so any more)

–Joel (with help from Yuping)

Update 2021 Feb 3 JMW: Creating pgplot and cpgplot on phasshare 64 bit virtual machine:

First, don’t ignore above advice about certain special files and their placement.

Second, Bruce and Joel could only get cpgplot programs to work by seeing how libcpgplot.a was created and linked , in psrchive  directory(much more below)!

To create a fresh pgplot and cpgplot that work, execute pgplot.csh in the bowels of psrchive:

/usr/share/astro/psrhome/src/psrchive/packages>
./pgplot.csh | tee /usr/share/astro/psrhome/pgplot/pgplot.csh.out
(tee sends the text  output to the named file  in addition to standard output). See a fuller description of what pgplot.csh does below.

(User must move the previous pgplot out of the way before running this script; ie
mv /usr/share/astro/psrhome/src/pgplot/ /usr/share/astro/psrhome/src/pgplot.older/)

(And I worry that maybe I need to move other random carcasses out of the way too.)

Some of the things done by pgplot.csh:
1. create a mother directory to put all necessary pgplot files into:
/usr/share/astro/psrhome/src/pgplot, after first moving aside the current tree there (see above).Actually it creates /usr/share/astro/psrhome/src/ and then will pour everything below it.)
2. Also create /usr/share/astro/psrhome/pgplot/ (I wonder if we should have moved old one out of way here too?)
3. get if necessary and gunzip and de-tar the pgplot 5.2  distribution (!)  and put it into and under newly created mother dir.
4 patch the png routines: Interestingly, there is a file
/usr/share/astro/psrhome/src/psrchive/packages/pndriv.patch which seems to suggest that there might indeed be probs with standard png driver, and it is pulled in by pgplot.csh and does seem to enable the use of png routines with pgplot and I assume cpgplot.
5. fix psrchive.conf
6. enable good output drivers
7. run /usr/share/astro/psrhome/src/pgplot/makemake with appropriate flags, creating master makefile, and ‘make’ -ing it and ‘make cpg’ -ing it.  As far as I can tell, the makefile made from this process is essentially identical to the earlier one(s), except that the earlier ones could not link in the png routines because they were broken, but the current ones are patched by pgplot.csh  (perhaps not in makefile itself but rather in something it calls.)

But for now consider the following:

lots of pgplot source files are in
/usr/share/astro/psrhome/src/pgplot/src/
cpgplot files are in
/usr/share/astro/psrhome/src/pgplot/cpg/  (see cpgplot.doc here for important help and note that pgbind.c ,which is run by ‘make cpg’, actually makes the libcpgplot.a I believe)

Note that the two above directories are not parallel nor do they have any other logical relative location!!!

pgplot executable etc dir is /usr/share/astro/psrhome/pgplot/  One can find things like makefile (manually placed there), libpgplot.a, libcpgplot.a cpgdemo, pgplot.csh.out (the text output of the proper building  of cpgplot (and pgplot) via running pgplot.csh as follows:
/usr/share/astro/psrhome/src/psrchive/packages>
./pgplot.csh | tee /usr/share/astro/psrhome/pgplot.csh.out  (tee sends the output to the file  in addition to   standard output)

Note makefile can be created by makemake in /usr/share/astro/psrhome/pgplot/src/pgplot and in fact running makemake in that dir places makefile there too, so I manually moved it up two directories.

makemake /usr/share/astro/psrhome/src/pgplot/ linux psrchive   [the latter three ‘words’  are the arguments of the makmake command], which erroneously dumped makefile into the above specified dir (upon its own reccomendation) so I had to manually mv it to /usr/share/astro/psrhome/pgplot/     .  In the end I had to make from the above  psrchive version in order successfully to create cpg or at least the png parts of it, and to successfully link cpgdemo.

then ‘make’ makes libpgplot.a  and ‘make cpg’ makes libcpgplot.a  (see steps near bottom of that file)!  There is a problem with png routines though that crashes? (or at least reports errors in) the make cpg  but the psrchive-generated makefile fixes this!

 

More serious problem with cpgplot (fixed by Bruce and Joel 20210204):
If I try to build any c (.c) or c++ (.C)  program and link it with cpgplot up thru Feb 3, it failed because it couldn’t find ANY of the cpgplot routines that the program tries to call. (eg the creation of cpgdemo inside the make cpg part of the makefile, or the pglink64plkc.C script for compiling and linking plkc.C in usr4/lk-lookey). Note that cpgplot is just a c wrapper to fortran pgplot routines and that is what is failing.  Long ago we had this problem and it was fixed by adding a trailing “_” to any fortran routine name.  I see that that is being done now but it doesn’t fix the problem (maybe it exacerbates it?). One example of failure (there are many, one for each unique call of a cpgplot routine):

{phasshare.physics.carleton.edu}:{jweisber}:/data/psrdata/usr4/lk-lookey> pglink64plkc.C
/usr/share/astro/psrhome/pgplot/libcpgplot.a(cpgbeg.o): In function `cpgbeg’:
cpgbeg.c:(.text+0x34): undefined reference to `pgbeg_’

The fix of Feb 4 was to model our 64bit compile and link scripts
(like /usr/share/astro/pglink64cpgdemo.C), on the (more automated) steps that
successfully create it in the makefile.  So now /usr/share/astro/pglink64cpgdemo.C is
my template for making other 64 bit, c compile and link scripts. . . .

I found on Feb 5 that .C (ie capital C) files like usr4/lk-lookey plkc.C can not use the same script as .c (ie lower case c) files because the .C files are c++.  After a (too long) while, I got working a script to do so.

So for a c file <filename.c> one types pglink64.c  <filename>  (with extension stripped off), and

for a c++ file <filename.C> one types pglink64.C  <filename>  (with extension stripped off)

( There may be slight path issues. )  Both scripts are in /usr/share/astro on phasshare

 

How to configure Oklular to show a document’s file name in its titlebar instead of the document’s “title property”

Published by jweisber on 2015-10-07

By default, the version of Okular available to CentOS 6 does not show the viewed document’s filename in the Okular window titlebar, but rather the value of the “Document Title” property embedded in the document being viewed. This is bad news because the Document Title property is usually set to the name of the app that created the document, making it difficult to tell multiple documents generated by the same app apart.

You can force Okular to set it’s window titlebar value to the name of the file being viewed by editing the file ~/.kde/share/config/okularpartrc and appending this line to the ‘[General]’ section:

DisplayDocumentTitle=false

When you finish, the file will end up looking like this:


[General]
UseKTTSD=false
DisplayDocumentTitle=false

 

Thanks Bruce!

mingw64-pkg-config.x86_64

Published by admin-joel on 2015-06-09

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

Published by admin-joel on 2015-05-21

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

Firefox: Run it on a host even if it you have it open on another – Bruce

Published by jweisber on 2014-08-25

Firefox setting for users who’s home dir lives on NFS – Bruce Duffy May 2013

Here’s how to tell Firefox that your homedir is sitting on an NFS filesystem:

This update (10.8) also fixes the following bug:

* In certain environments, storing personal Firefox configuration files
(~/.mozilla/) on an NFS share, such as when your home directory is on a
NFS share, led to Firefox functioning incorrectly, for example, navigation
buttons not working as expected, and bookmarks not saving. This update
adds a new configuration option, storage.nfs_filesystem, that can be used
to resolve this issue.

If you experience this issue:

1) Start Firefox.

2) Type “about:config” (without quotes) into the URL bar and press the
Enter key.

3) If prompted with “This might void your warranty!”, click the “I’ll be
careful, I promise!” button.

4) Right-click in the Preference Name list. In the menu that opens, select
New -> Boolean.

5) Type “storage.nfs_filesystem” (without quotes) for the preference name
and then click the OK button.

6) Select “true” for the boolean value and then press the OK button.
(BZ#809571, BZ#816234)

All Firefox users should upgrade to these updated packages, which contain
Firefox version 10.0.8 ESR, which corrects these issues. After installing
the update, Firefox must be restarted for the changes to take effect.

Make Evince Display IDL PS Filename on Banner: JUST USE EVINCE!

Published by admin-joel on 2014-08-19

AS OF 2020 Sep (and I believe much earlier), using the graphics displayer EVINCE automatically puts filename on banner, and furthermore the following did not work with other viewers. Therefore consider the following to be “deprecated” (withdrawn) –jmw

To  actually use evince from the command line, type evince <filename> &

To actually use evince in a nautilus file manager, select (click on) the desired file, and go to
file>>open with>>evince

Commonly when one prints plots to a postscript from IDL and open it with evince(as we always do), the banner of the evince window perennially shows “Graphics Produced By IDL”, which is not helpful at all especially when you’re plotting a thousand plots and trying to compare them.

Hence a pair of IDL routines (OPENPS and CLOSEPS )can be called now to make the output PS file display the file name at the banner and to make the plotting to file process slightly less complicated. The way to call them is as follows:

OPENPS, blablabla.ps      //Before you plot anything. This will set the output device to blablabla.ps and by default color plot

[ DEVICE, FONT_SIZE=9]  //This is the optional part if you want anything about the graph beyond color, see IDL documentation on DEVICE for more

//information. Note that you may overwrite the color attribute here by saying DEVICE,/COLOR=PS

plot,bla

overplot.bla //Plot and add labels and do whatever as you like

CLOSEPS //When you’re done with one graph, simply call CLOSEPS, it will save the file for you and set the plotting device back to xwindows

WARNING: DO CLOSEPS BEFORE YOU OPENPS A NEW FILE. IN OTHER WORDS, EACH PLOT FILE MUST BE ENCLOSED BY A PAIR OF

OPENPS-CLOSEPS statement.

For more information, the code locates at /usr/share/astro/idlshare/locallib, or email huangy@carleton.edu.

 

-yuping

tempo2,fftw3 and cfitsio setup

Published by admin-joel on 2014-08-13

TEMPO 2 is the newer pulsar timing package. FFTW3 is a fast fourier transformation library. CFITSIO is the NASA library for reading FITS format images. All of them are installed under $PSRHOME.  there’s another installation documenting file 00READMECarleton under that folder. FFTW3 and cfitsio are the dependencies for some of the tempo2 plugins and psrchive.

1. FFTW 3.3.4 is obtained from http://www.fftw.org/download.html,  unzip the tar file then

./configure –prefix=$PSRHOME/FFTW3/
sudo make
sudo make check
sudo make install

This will install the double precision FFTW3 library for TEMPO 2. However, the single-precision fftw
library that psrchive might require is not installed yet.

2.CFITSIO 3.370 is obtained from http://heasarc.gsfc.nasa.gov/fitsio/, unzip, cd, then

./configure –prefix=$SOFTWARE_DIR
sudo make shared
sudo make install

3. TEMPO2 is obtained by CVS anonymous checkout
cvs -z3 -d:pserver:anonymous@tempo2.cvs.sourceforge.net:/cvsroot/tempo2 co tempo2

The installation requires an amount of modification of config files (pgplot compilation flag, fixing bugs).
See 00REAMECarleton for details. But basically you do

./bootstrap
 setenv TEMPO2 $PSRHOME/tempo2/
 ./configure --prefix=$PSRHOME/tempo2/ --with-cfitsio-dir=$PSRHOME/cfitsio/ --with-fftw3-dir=$PSRHOME/FFTW3/ F77=f77
 sudo make && sudo make install
 sudo make plugins && sudo make plugins-install

-Yuping

printing postscript images to printer with gv (ghostview) as backup to evince

Published by jweisber on 2014-02-06

Bruce installed the gv package for viewing and printing postscript.  It works great for viewing.  For printing, it has problems.  Bruce developed this workaround (with a few mods by Joel):

‘gv’ uses the ‘lpr’ command, and if a printer as set as the default in CUPS it will use that printer automatically.  You can hear the printer warm up, but nothing comes out of the printer.

Fortunately ‘gv’ is packaged with a set of file conversion utilities,
including ‘ps2pdf’.  On the command line you can issue this command:

# ps2pdf xxx.ps – | lpr

and that will convert the ps file to pdf (version 1.4) before sending it to lpr.  (You can also convert in place – ie turn your postscript file into a pdf on disk with ps2pdf, and then send the pdf to the printer whenever you want.)

To print a ps on the fly, though:
gv’s print command dialog window has a typein labeled ‘print command’
and it’s automagically populated with the string ‘lpr’.  However you
can change that string to ‘ps2pdf %s – | lpr’.  You can also change
the default print string from ‘lpr’ to whatever you want in
GhostScript options, but that would break printing of non .ps Here’s.

To change the default print string in ‘gv’, select:

State->Setup Options

… Look for the Print Command field, and change the value from
‘lpr’ to ‘ps2pdf %s – | lpr’ (w/o the single quotes).

The change is saved to ~/.gv as the line:

GV.printCommand:        ps2pdf %s – | lpr

 

–bruce via joel