Comments on the Windows distribution of Science Tools

This page is a summary of some problems related to installing and running science tools under Windows. For some of these, work on fixes may already be in progress. Except for possibly the lack of support for FTOOLS on Windows, these are not insurmountable problems.

  • Three of the science tools (gtobssim, gtorbsim, gtburstfit) will not run as delivered unless the user has the VC development environment installed. The problem is that the C runtime library MSVCR71D.dll (D for Debug) cannot be found. The installer in fact installs it, but the wrapper scripts generated by the RM do not point to it. Apparently this is a fairly deep problem with how the tools are built; the reason that many of the tools want to have access to MSVCR71D.dll is only because cppunit, a testing program, wants it. For the 3 above-named tools, the problem is somewhat deeper in that the RM does not seem to be able to automatically determine that the tools are going to think that they want the MSVCR71D.dll. Work arounds come to mind, like having the RM always put the DLL in the Path variable.
  • We are currently distributing only debug builds in VC8. My understanding is that there's no fundamental reason for not making optimized builds, but the difficulty is in finding a way for the RM to get the information it needs from build logs on Windows via lsf.
  • The RM still installs all of the test applications and assorted applications that are not intended for users. This is not a Windows-specific issue, of course.
  • The wrapper scripts always start a new command window when a tool is started. This is inconvenient for all of the tools, not just for the tools like ModelEditor that do not need a command window at all. The new windows do not go away after the tool completes running, and all of the various variables like Path and PFILES that the wrapper scripts modify just keep getting longer if a tool is run from one of these new windows (which in turn opens another Window). Also, I imagine that any kind of scripting together of the wrapper scripts would be problematic.
  • The wrapper scripts do not work if the tools are installed in a directory path that has a space in its name. This is an especially attractive nuisance because so many directories in Windows have spaces (like 'Program Files') and the default installation directory suggested by the Java installer is most likely within 'My Documents'. The fix is not difficult.
  • FTOOLS in general are not available under Windows. Although the very useful fv tool does have a Windows version, the utilities for manipulating FITS files are quickly sorely missed. I do not think there's any momentum or motivation for HEASARC to support FTOOLS under Windows.
  • Connecting ModelEditor with ds9 is in principle possible, but I have not managed it yet. This is not a problem with the RM, and maybe not even Windows specific, but enough additional work has to be done (installing a Python DS9 library and installing and compiling XPA) that we really cannot realistically expect users to do them. To the extent possible and reasonable, we should integrate the installation of the science tools and their interfaces to Python and ds9.
  • No labels

2 Comments

  1. Navid Golpayegani

    • gtobssim, gtorbsim, gtburtfit can't run not because of the RM but because of the problems with GlastPolicy, CMT and requirements file. The temporary hack to get it to work is to make st_facilities use cppunit in its public section and not the private. This is a hack but it's one we'll have to do for now. The long term solution is an overhaul of the Policy packages to be smarter. This is a major change and will most likely require modification in all the requirements files.
    • VC8 builds should now happen. I'm still waiting for a tag to occur to test this part out in RM.
    • Wrapper scripts always staring a new command view is a problem of WSH. I'm still working on this. The problem is that when executed in the current shell the application fails to find the dll files while when executed in a new shell the dll files are available. As for the new shell not closing: I can change that easily to automatically close the shell when done. I decided on leaving the shell open because I figured users would be interested in the output of the application. If that's not the case it's an easy change.
    • The wrapper scripts do work with directories that have spaces. I have confirmed this with test_Likelihood.vbs (and all other parts) installed in "c:\glast blah". I believe what's not working with spaces are the programs that the wrapper scripts end up calling.

  2. Seth Digel

    • Thanks for the good news about the VC8 builds and about the scripts.
    • I had not heard that you had fixed the problem of handling installation directories that have spaces. Thanks for that, too.
    • Regarding whether the tools themselves can handle spaces in the file names, that seems to be kind of a mixed bag. No one has reported problems along this line; I haven't tried it exhaustively myself, but the one tool I just tried (gtobssim with the wrapper script hacked to have MSVCR71D.dll in the PATH) handled spaces in the input file name and directory names just fine as responses to PIL. But given as command line arguments (e.g., scfile="SC FT2.fits"), they didn't work at all
    • Yes, users would be interested in the output of the application, especially in the case of errors.