I (Joel) noticed that a lot of our old IDL programs are stored in /usr/share/astro/idlshare/local/
Carleton Astronet Admin Log
I (Joel) noticed that a lot of our old IDL programs are stored in /usr/share/astro/idlshare/local/
all this and more is in /data/psrdata/usr4/lutzkelker/APJsourcecode/createProbForD.pro :
creating histogram with coyote cghistoplot and with a simple plot object
decoding systime() into a string of yyyyMOdd-HHmi for filename writeout with date&time embedded
but note that the function call may need to be all lowercase!!!!!Also note that above program now calls the function which resides in the path at /usr/share/astro/idlshare/locallib/getyyyymoddhhmi.pro , and that it is called in main as: mydatimestring=getyyyymoddhhmi(). And furthermore that one can test for existence of a routine in path by typing from command line: print, file_which(‘getyyyymoddhhmi.pro’)
writing out a postscript from an old style plot procedure and from an already-generated plot object (extremely easy!)
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.
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!
gang_plot_pos.pro is a nice routine for “ganging” multiple plots onto a single sheet.
I have moved it into /usr/share/astro/idlshare/locallib , which should be in your idl path. therefore you can use it without ever having to manually compile it.
Joel
On June 11, 2014, Yuping Huang said:
I just realized that fsc_color is no longer available because the shared Coyote library was updated a couple weeks ago. So yes the library was updated from its previous early 2000s version. The development for fsc_color stopped at 2011 so now it is not in the library any more, with CGPlot as its successor.
Hence, if you are calling Coyote stuff in idl and found idl telling you that it does not exist, you might want to check the latest Coyote source code online to see if it has been expelled from the library.
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
canopus,deneb (both up against the window) and mirzam (in Joel’s office)
One might want to plot to screen, interactively adjust parameters, replot to screen, etc; and then when done fiddling; make a final postscript plot. However, . . .
As far as I know, it is a little complicated to plot both to screen and to postscript. One has to send essentially the same commands to each “device”, while also opening and closing them properly.
A good example of doing this is in combine_v7.0.pro, in /usr/share/astro/idlshare/local/recombo2008
————————————————————————————
A simpler version of this problem is the either/or problem – ask user whether she wants to plot to screen OR postscript.
A good example of this is profile_v4.5.pro [in its pro make_plots]
–Joel
The following was significantly updated on 30 May 2012 and again on Aug 2014:
idl and pgplot and many other postscript plotting routines have this annoying “feature” wherein, the output postscript file, when displayed with evince (“evince <filename> &”), goes into a window whose banner does NOT give its filename. This is confusing if one is looking at multiple files. We would prefer that the banner gives the name of the displayed file.
E.g., if the postscript file was produced with pgplot, the window banner says “PGPLOT postscript plot”, rather than giving the file name.
E.g., if the postscript file was produced with IDL, the window banner says “Graphics produced by IDL”, rather than giving the file name. (NOTE ADDED AUG 2014: YUPING HAS CREATED A SCRIPT INSIDE IDL TO GENERATE A FILENAME TAG ON PS FILES. SEE HIS POST!)
The reason is, that it writes into the file itself that the title is “PGPLOT postscript plot”; i.e., it literally writes “%%Title: PGPLOT postscript plot”
(or something similar for the IDL) into the postscript file.
After much effort, I have realized that evince will automatically display the desired filename rather than the above useless info, if only
one eliminates the whole “”%%Title” line. (My first solutions, rather than eliminating that line, wrote the filename in the “%%Title” line.)
Inside IDL itself, I think it is not possible either to alter or to eliminate the %%Title line as the postscript file is written because the drivers are proprietary. Therefore one must fix the postscript file afterwards. (The web shows how to run a unix script inside IDL that does so.)
Inside pgplot itself, one CAN fix the drivers so as to eliminate the offending %%Title line: Go to drivers/psdriv.f
———–
To fix up a postscript file after the fact:
Joel has written a script (whose original was made and embellished by Joe Swiggum), joelpslabel, which
1. writes a new file whose name is the same as the original postscript file except
–Its name has an added “label” before the dot in the original file name
–Its modification date is listed as being identical (at least to the minute) with the original file name (as in “ls -al”) so that you know when the original was created. (This was hard!!!!!!!!!!!!)
2. The script then runs evince on the new file, thereby putting on the screen something identical to the old file but with a banner that gives the old file name
———————
The new file with the new name having “label” in it stays on disk, and the original file is untouched, and they both have the same (claimed) date on them. I do this because an older version of this script, which actually overwrote the original, sometimes got confused and the original was destroyed, requiring an archival search of old backups. The downside is of course twice as much disk space but hey disk space is cheap and easy these days.
One can run joelpslabel on the original file as many times as one likes – each time overwriting the “new” file but assigning it the date of the orig file.
One can also run evince on the new file infinite times. The only downside there is that the banner will give the newfilename the 2nd-infinite time, rather than the old file name. (The newfilename = oldfilename + “label”)
Known problem: The script searches for the first “.” in the filename and places “label” before it, so if your filename has more than one dot before “ps”, the name will be very screwy. joel.weisberg.ps -> joellabel.weisberg.ps