Urania

A blog named for the muse of Astronomy containing musings by an astronomer

Archive for the ‘IRAF’


HINT: Another (probably better) solution, to g77 flakeiness in IRAF on Mac Intel 0

Posted on October 15, 2007 by Juan

The IRAF.net forums had a post from someone having issues getting the IRAF package rvsao to compile properly on MacOS X on Intel-based Macs. I’ve commented about this before and had discussions with Doug Mink, the fellow behind rvsao as I have battled to compile it. It’s not actually that tricky, you just have to be careful. The key issue is that the most commonly used g77 compiler on Intel-based Macs is probably g77 version 3.4 as downloaded from the High Performance Computing for Mac OS X site. This version of g77 is a bit more picky about logical statements. Specifically, when you try to compile rvsao within IRAF using mkpkg, you get the following error (as noted by Phil Massey in the IRAF.net Forums earlier today):

I’m trying to install the external package rvsao on my Intel mac. However, when I go to do the mkpkg there is a program “writetemp.f” that won’t compile:

In subroutine `tmpwrf':
writetemp.f:139:
if (.not.(debug .eq. .true.)) goto 130
1 2 3
Use .EQV./.NEQV. instead of .EQ./.NE. at (2) for LOGICAL operands at (1) and (3

I was having exactly these sorts of errors with not only rvsao, but several of the SAO IRAF packages this summer and after banging my head on this a bit, I found a solution that worked for me. It turns out g77 needed to be told to use less restrictive logicals via a “-fugly-logint” flag during the compile. So my solution was to write a perl script that was saves as /usr/local/bin/f77, such that when f77 was called (by these IRAF mkpkg calls) it would issue a g77 call with this flag set on the compile. So I posted about this on that IRAF.net forum thread started by Phil Massey.

I got a response from Mike Fitz where he points out that you can set up the XC compiler used by IRAF to always use these flags via environmental variables:

If you use ‘g77’ all the time and need this flag it can be set for all compilations either in the user environment (e.g. your .cshrc file) using:

Code:
setenv XC_F77 g77
setenv XC_FFLAGS “-fugly-logint”

or for problematic packages you can edit the ‘mkpkg.inc’ file for the package (normally in the pkg$lib directory but in the case of RVSAO it’s in the main rvsao$dir) to add “-/fugly-int” to the ‘XFLAGS’ definition. The ‘/’ tells the XC compiler to pass the flag thru to the underlying compiler unchanged, but note this sometimes causes problems or warning if say g77 knows the flag but gcc doesn’t (i.e. the XFLAGS are passed to all sources being compiled, you’ll need the XC_FFLAGS trick to pass only to fortran code).

Scisoft OSX Intel 2007.9.1 released 0

Posted on September 18, 2007 by Juan

Another new version of Scisoft OSX for Intel has been released and is available for download here. Here’s the entire description of the changes in this version of Scisoft OSX from the release notes:

This version contains an updated [ESO-]MIDAS package.         

I checked the list of packages included and sure enough, the only change was in the ESO-MIDAS package (whose current version is actually 07SEPpl1.0).

I don’t use ESO-MIDAS, which is an image reduction package aimed as users of ESO’s La Silla facilities and the VLT at Paranal, so I can’t really comment as to the usefulness of this update. As with previous versions of Scisoft, the release notes warn if you use Aquaterm devices for PGPLOT, GNUPLOT, or any other packages that you “must manually run /scisoft/i386/Applications/Aquaterm.app once first to enable the aquaterm devices.”

I have also confirmed that this release also fixes the IRAF problem with symbolic linking to mkpkg and xc in /scisoft/i386/bin/ I referred to earlier in my blog.   Thanks for the fix guys!

Finally, as I noted with the last release of Scisoft, my standard method for updating Scisoft OSX is to move my existing /scisoft directory to /scisoft_old and then I unpack the new version. That way, in case anything goes wrong, I can always switch back.

Scisoft OSX Intel 2007.7.1 released 0

Posted on August 15, 2007 by Juan

Francesco Pierfederici and Nor Pirzkal have released a new version of Scisoft OSX for Intel which is available for download here. Here’s a quote from their blog about the changes:

This version is contains the latest STSDAS and TABLES Iraf packages as well as updates of a few packages.Startup scripts have also been modified to try to get around conflicts with Fink. Please let me know if you are still getting problems with Scisoft when Fink is installed.

I checked the list of packages included and changes that I was able to identify versus Scisoft OSX 2007.1.1 include:

The release notes warn if you use Aquaterm devices for PGPLOT, GNUPLOT, or any other packages that you “must manually run/scisoft/i386/Applications/Aquaterm.app once first to enable the aquaterm devices.

My standard way to install Scisoft OSX updates is to move my existing /scisoft directory to /scisoft_old and then I unpack the new version. That way, in case anything goes wrong, I can always switch back.

HINT: Resolving xgterm problems calling ecl scripts 0

Posted on August 09, 2007 by Juan

I am posting here an annotated version of one of my headaches for the last few days, which has been a persistent xgterm crash. I have been working on getting the Hectospec reduction scripts known as specroad running on my Macintosh (something I will fully document and provide binaries for when I am done). Having never done spectroscopy before, it seemed like a safer bet to learn by working my way through their scripts than trying to invent this as I go. Some magic done by the specroad scripts comes from the fact that they call IRAF routines in the form of ecl scripts, allowing two or more separate simultaneous IRAF processes. On a multi-processor system like mine, this parallelization can help cut down on the running time. More specifically, the specroad package contains a script called ‘callhectospec‘. This script calls ecl, the enhanced IRAF command line environment, and then sets up the environment by loading the hectospec package in IRAF. It then issues the IRAF command you requested. I was having a problem running the command:

xterm -e callhectospec hcal comp.ms
to calibrate the pixel to wavelength mapping because it would bring up a Tektronix window (via xterm’s Tektronix emulation), but I wasn’t able to type out the proper commands within that window. I suspected that I was triggering some sort of internal Tektronix commands, and so I tried switching the call spawn an xterm witha call to X11IRAF’s xgterm. xgterm is a xterm clone that offers more advanced plotting capabilities and interactions. The callhectospec script immediately crashed with the following error:
 Error in message to server, line 6: send: could not find object gterm
    while executing
"send gterm setGterm"
xgterm Xt error: Shell widget gterm-iraf has zero width and/or height
I spent a few hours searching for solutions in Google. All the previous instances of this error seemed related to running old versions of X11. This didn’t match my situation. I tried upgrading xgterm to the current version, which didn’t change things. It was a bit irritating because I knew IRAF worked with xgterm just fine. Clearly I was triggering this error message for a reason that didn’t match the previous cases. I finally relented and posted about my problem on IRAF.net‘s forums. Thankfully, the solution, pointed out by Fitz, was simple, the callhectospec script was setting up the IRAF environment for xterm, not xgterm. All I needed to do was edit callhectospec to replace
else if (envget("TERM") == "xterm") {
 stty xterm
}
with
else if (envget("TERM") == "xterm") {
  stty xgterm
}
My IRAF login.cl script does exactly this, which is why it worked when I entered ecl by hand. Once that was fixed, everything worked like a dream.

Read the rest of this entry →

Annoyance: IRAF in Scisoft OSX mkpkg glitches 1

Posted on August 08, 2007 by Juan

Update: I have updated this blog entry to reflect some updated information from Nor Pirzkal regarding the best way to fix this glitch.  This problem has been fixed in Scisoft OSX MacIntel version (2007.9.1).

During my adventures compiling the hectospec-related IRAF packages, I was using Scisoft OSX and discovered there were a couple of issues with the symbolic links for the mkpkg command necessary for compiling new IRAF packages.

  • In the Scisoft OSX PPC Beta (2006.11.1b) mkpkg appears to be mis-linked, so it can’t be executed. So I did the following in the terminal:
    cd /scisoft/binsudo rm mkpkgsudo ln -s ../iraf/iraf/unix/bin.macosx/mkpkg.e mkpkg
  • In the Scisoft OSX MacIntel version (2007.1.1) and Scisoft OSX MacIntel version (2007.7.1), there are some missing symbolic links to mkpkg and xc in the directory for MacIntel binaries.  As a result, both mkpkg and xc were instead pointing to PowerPC binaries. I fixed this as follows (again, from the command line):
    cd /scisoft/i386/bin/sudo ln -s /scisoft/all/packages/iraf/iraf/unix/bin.macintel/mkpkg.e mkpkgsudo ln -s /scisoft/all/packages/iraf/iraf/unix/bin.macintel/xc.e xc
    This mis-linking certainly didn’t help getting things to compile under MacIntel, since IRAF was attempting to compile MacIntel code using PowerPC versions of mkpkg and xc.

Thanks for Nor Pirzkal for giving me some feedback on fixing this problem.  He tells me he has made the appropriate changes so that the next version of Scisoft OSX will not have this  issue.By the way, my complaint here should in no way be construed as a critique of the efforts of Francesco Pierfedericki and Nor Pirzkal in putting together Scisoft OSX. They have done a great deal of work to put together an awesome package. For two people to track over 2 GB of software and not expect some glitches is unrealistic. And I for one am extremely grateful that his efforts have saved me a lot of time.

  • Translate

  • Astro Pic o' the Day

  • Archives

  • Admin



↑ Top