iraf.net

Is anybody successfully running IRAF in Windows using a Linux docker container? I've built a linux container with IRAF (via Astroconda) and it seems to work except for the fact that I can't access (from within IRAF) files on the host machine. The container sees the files and I can create and manipulate them from the Linux command line, but IRAF's VOS cannot see the files. In other words, 'dir' cannot see the files, but 'ls' (a foreign task) can. Here's an example, using a directory (data) that corresponds to a directory on the Windows host):

ecl> cd data
ecl> dir
.
ecl> ls
bar.txt foo.txt yo.txt
ecl> print hi > test.txt
ERROR: cannot open `test.txt' for writing
ecl> !echo hi > test.txt
ecl> ls
bar.txt foo.txt test.txt yo.txt

Any ideas for what might be happening here?

Bob

I don't have access to a Windows system to try it, however my guess would be that the 32-bit binaries in the Astroconda distro aren't able to read the 64-bit file system in the underlying Windows. On linux systems this was caused by the 64-bit inodes not being understood in the iraf kernel. Installing a 64-bit IRAF in the Docker might fix it.

Hi Mike,

Thanks a bunch, I'll try that and see if it fixes things! I'll then be stuck with lack of STSDAS though.

Windows usage around here is on the rise (because the Windows subsystem for Linux kind of gives you both worlds), so the absence of a 32-bit STSDAS is proving a big hassle. Do you have a ballpark estimate for how many FTEs it would take to do the port to 64 bit? Given how NOAO and STScI are mainly focused on other things (with the notable exception of you keeping the ball rolling here), I wonder if the community could suggest to STScI they handle the port. Or perhaps I could find the resources here to have somebody take it on. I guess the issue isn't the money so much as finding somebody skilled enough in SPP to take care of it.

Regards,

Bob

P.S. If for some reason you would like access to a Windows development machine for IRAF let me know.

Oops I mean "absence of a 64-bit STSDAS" of course.

Bob

STScI has stated they have no interest in doing a 64-bit STSDAS themselves and are in the process of rewriting what code they want to preserve in Python or as part of the JWST effort. The TABLES package is in the same boat however the TTOOLS tasks were included as the NTTOOLS package in v2.15 and do have 64-bit binaries. There is a community effort underway on GitHub to produce debian installs but I don't think there are plans for a 64-bit STSDAS anytime soon due to what they see as licensing issues.

Hmm... a couple of years ago I chaired a subcommittee of the JSTAC (reporting to STScI) charged with assessing the preparedness of the JWST software stack for community data analysis. Because we took the ubuiquity of IRAF as a given, we focused mostly on the python tools. But this 32-bit vs. 64-bit STSDAS/TABLES thing is exactly the sort of issue we would have highlighted if we'd been aware of it. Two years ago the WSL didn't exist and way fewer astronomers were using Windows, and nobody was worrying about Docker container interoperability issues.

Anyay, the folks at STScI are trying to do the right thing for the community... the last thing they want to do is to have the tools get in the way of speedy JWST data processing. I'll write Ken & Co. and suggest they take a look at whether a 64-bit port of STSDAS and TABLES might make now make sense given how things are evolving. It would also be a good idea to relay this suggestion to the JSTUC (which replaced the JSTAC, since we thought we were less than a year from launch!).

RE: licensing issues related to a Debian port... I find that my sanity is best preserved by staying at least a kpc away from the minutiae of software licensing. As far as I can tell, NOAO has always made it clear that it wants to release IRAF to the community in an open a way as possible. Of course, lawyers can turn anything into a quagmire.

Good luck, I'm sure there are those in the community who would appreciate the push even if the Institute doesn't 8-)

The biggest licensing issue with STSDAS is the use of Numerical Recipes code: NOAO has permission from one of the authors to use some routines in the core system but this doesn't cover external packages. Several years ago the STSDAS distribution started being released without the source code for the NR routines so it isn't even possible to completely build the package unless you have an old version and can patch the sources back in.

I don't think a 64-bit port would be hard given the things to look for in the SPP code are already documented. Porting the pure C/Fortran code in e.g. hst_calib may be more intensive but I think this is the focus of the Python rewrite effort anyway. A fair compromise might be to extract packages like ISOPHOTE, FOURIER, TIMESERIES, etc and port them individually as new packages rather than doing the whole thing (ideally with ST's blessing if done as a community effort).