None of our SGI computers with Irix 5.3 are able to run the new version. Only SGIs with Irix 6.5 runs the program. Is there are fix for this problem?
New HKL version does not support the old operating system.
We have been using denzo/scalepack on our dec alpha, but up to now we have only run it as jobs in background, we are now trying to use the display program and we are having problems. Xdisp comes up OK, and we can run denzo and @denzo.com with a command file, but when we get to the point where it should put up the predicted pattern, xdisp crashes with this error message: 'Segmentation fault (core dumped)' . We are using adsc unsupported-q4 type images. We have tried rebooting the system and using unlimit to increase the amount of memory available, but neither of these helped.
Try not to run anything else (like Netscape), but xdisp.
Problem with version Denzo1.96 for DEC Alpha station: When we run xdisp. After several seconds it displays '>Image Ready' in a command window. And everything works good unless one executes probably the most important command, Peak Search, when the program terminates with a message: '>Floating exception (core dumped)'. I hope You know, how can we deal with this problem?
This problem has been fixed in release 1.96.3. You must have an earlier version of the program. Please download the newest version.
In response to many questions about the current system requirements we have created Hardware and Operating System Recomendations page.
- You should never economize on swap space because otherwise the programs may get killed randomly by the operating system.
- OSF-Digital Unix and IBM AIX set default datasize to unrealistically low values. Datasize should be set to unlimited, when the HKL programs are run.
I get the following error
Problem with hardware recognition
Field HOST-NAME
Error code: 6
HOST-NAME line in the info file must have changed. Please re-run the access_prod program on that computer and send to hkl@hkl-xray.com. Your access file, cr_info, needs to be updated.
When I ran xdisp ccd adsc unsupported-q4 xxx2_1_001.img 1. I received the following error: 'timer error or current directory name too long, error code -2'
Timer error means that the checking program found that the time of your computer has been changed. Usually it happens when the system clock is set backward. Check /etc directory, if you do not have files that have the dates 'in the future'.
When I increased the swap partition on the alpha to 1.5 megablocks (running tru64 4.0F, BTW) and I now get an error that says /sbin/loader fatal error program datasize exceeds process datasize limit.
On OSF (Digital Unix) operating system you have to set all resources (as it was on VMS) to the appropriate level. The best is to increase datasize to 'unlimited'.
Unfortunately I have problems with Denzo package. Here, we have the Open VMS AXP v 1.0. Running any *.exe I get this message:
$ run ccd
%DCL-W-ACTIMAGE, error activating image LIBOTS
-CLI-E-IMGNAME, image file DKA300:[SYS0.SYSCOMMON.][SYSLIB]LIBOTS.EXE
-SYSTEM-F-SHRIDMISMAT, ident mismatch with shareable image
Thinking that this error was due to fact that I have an old version I got the LIBOTS.* from the v 1.5. I still have the same error.
You need Open(vms)AXP v 6.1 to run Denzo. Upgrade your operating system.
Is the new Scalepack slower than the old one?
Scalepack speed is about the same. Postrefinement may take a lot of extra time, and very old versions had no postrefinement, however postrefinement is optional now so it can be as fast as the old one. Subjective variation in the speed of the program may be strongly affected by other programs on the same computer, in particular if the operating system starts to swap programs.
While I was trying to index the data from a twinned crystal, the Denzo always quit on me with a simple error message "Killed". Then, I realized that it occured to me once when I was processing the other data set from a "good" crystal. At that instance I logged off and rebooted the system. Afterwards, everything was OK. However, this time the system is corrupted seriously with error message of disk I/O error on rebooting. Besides, the window management files must have been corrupted because the PC icon-styled login window disappeared instead it gives me a dumb-terminal styled login window and every step runs very slowly. A check on /usr/adm/SYSLOG found the error message as,
By the way, my machine has 32 Mb main memory. It should be sufficient according to your manual. My best (uneducated) guess is that the program's memory management might have some serious flaws.
Message killed is from operating system running out of swap (not memory!) space. Swap space is shared by all programs, so it is dependent on how many processes are active, you can run out of swap space in unexpected moments. This has nothing to do which data set you process. Rebooting the computer killed some other programs and increased the amount of swap space for Denzo, however rebooting computers can make life difficult if your system is not well managed. Find a better system manager.
We would like to use Denzo on our SUNs running Solaris 2.2 if that's not too much trouble for you. They are 50 MHz 2-processor machines with plenty of memory, so I'd be surprised if they were inadequately slow. For the time being the only other machine we could use for Denzo is our DECstation 5000, but that's slower.
Both SUN's and DECstation 5000 are OK, but you run the risk of problems with the programs specific to these machines that program authors may not be aware of.
I told you that we have a SGI Power Series with VGX Graphics. This will handle your program, correct? Any special hints?
No hints. You will not take advantage of VGX graphics over standard entry level graphics.
What have you done to Scalepack such that it now exceeds any page file quota which I have and which runs the older version quite happily?
Increased allocation of memory for storage of reflections.
Also, are you still supporting your IPVIEW/Denzo package for SGI machines? We have noticed some binary executable incompatibilities between our platform and older ones which are meant to be compatible.
SGI creates hopeless number of almost compatible releases of operating system. SGI are generally supported, however older versions (4.0.5 or so) may produce problems.
I'm not sure what the byte-swap of the image is.
Denzo and Scalepack are now educated enough about little-endian and big-endian computers, so both programs can cope with byte-swapping problems automatically.
Comments: On UNIX (OSF) computers you may install all programs in /usr/local/bin directory (remember that only root privileges allow you to do that). Check if in your path statement /usr/local/bin is included. Another strategy is to put all files in arbitrary directory, for example /usr/users/wladek/HKL and add to your .cshrc file a bunch of aliases like:
alias denzo '/usr/users/wladek/HKL/denzo '
alias ccd '/usr/users/wladek/HKL/INST_CCD' etc, etc.
On VMS system, you can put all files in any directory. You should set-up logicals by including into your login.com file a bunch of commands like:
$ kodak :== $zbyszek:[wladek.distr.vms]cornell.exe
$ fuji :== $zbyszek:[wladek.distr.vms]fuji.exe
$ rx :== $zbyszek:[wladek.distr.vms]rx.exe
$ rxs :== $zbyszek:[wladek.distr.vms]rxs.exe
$ mar18 :== $zbyszek:[wladek.distr.vms]hamburgn.exe
$ mar30 :== $zbyszek:[wladek.distr.vms]hamburgd.exe
$ embl :== $zbyszek:[wladek.distr.vms]hamburg.exe
$ denzo :== $zbyszek:[wladek.distr.vms]denzo.exe
I am very happy with Scalepack and am trying to use it to look at data from a Xuong-Hamlin detector. The .ar files were on a MicroVAX where the data was collected, and I moved them over to an IRIS Indigo to run Scalepack. I have been using the following input file, but I get the following error:
endfile: end of file -1
apparent state: unit 5 named
last format: (132a1)
lately reading sequential formatted internal IO
This occurs even if I specify a non-existent file after the keyword file. Do I need to include another keyword, such as file size?
Hamlin Archive files are binary and have to be processed with Scalepack on the same type of computer. If you did reduce Hamlin data on VAX you have to run Scalepack on VAX or Alpha-VMS. SGI version of Scalepack does not understand VAX Hamlin binary files. Sorry.
Comments: Avoid byte swapping of raw data with command dd conv = swab. Better to do it in Denzo. Program dd may incorrectly change header information that may be useful.
Comments: On SGI one must load the files using /dev/tapens wnich tells it not to swap the bytes (/dev/tape, the default, does a byte swap to conform to ANSI standards…). To wit, if you try to load using /dev/tapens tar will complain about checksums and formats and then abort. Load using /dev/tapens then use dd conv=swab.
We would like to process our data on a VAX/VMS (old-style) machine, although we can also use HP and SGI workstation. Therefore we would be mostly interested in VMS version of Denzo (for R-axis and also synchrotron data).
Why use VAX if you have SGI and HP?
I ran the programs on a SGI running the 5.1.1.2 operating system, and I see they were compiled on 4.0.5. UN:csh: ERROR: cannot execute binary file UN:csh: ERROR: Scalepack - Exec format error
The new version of Scalepack doesn't seem to run on our SGI machines. I get an error message ("Scalepack: Exec format error. Wrong Architecture."). I've tried IRIX versions 4.0.5 and 5.1.1.2. Any ideas?
You probably try to run Scalepack compiled on OSF or other brand of computer.
Do you have a Alpha/VMS version of the latest stuff?
Yes, however future versions (1.9 and higher) will not run on Alpha/VMS.
Error message from my computer:
mard TGABND_001.IMAGE
%LICENSE-F-NOAUTH, DEC DW-MOTIF use is not authorized on this node
-LICENSE-F-NOLICENSE, no license is active for this software product
-LICENSE-I-SYSMGR, please see your system manager
%TRACE-F-TRACEBACK, symbolic stack dump follows
Install properly your window manager.