Trouble with Input and Output

General

1. Q: I want output from printf to appear immediately.


A: This is really a feature of your C and/or Fortran runtime system. For C, consider




setbuf( stdout, (char *)0 ); 

or


setvbuf( stdout, NULL, _IONBF, 0 ); 

Workstation Networks

1. Q: I want standard output (stdout) from each process to go to a different file.


A: mpich has no built-in way to do this. In fact, it prides itself on gathering the stdouts for you. You can do one of the following:

1. Use Unix built-in commands for redirecting stdout from inside your program (dup2, etc.). The MPE routine MPE_IO_Stdout_to_file, in mpe/src/mpe_io.c, shows one way to do this. Note that in Fortran, the approach of using dup2 will work only if the Fortran PRINT writes to stdout. This is common but by no means universal.


2. Write explicitly to files instead of to stdout (use fprintf instead of printf, etc.). You can create the file name from the process's rank. This is the most portable way.

HP-UX

1. Q: When trying to run upshot under HP-UX, I get error messages like


set: Variable name must begin with a letter. 

or


upshot: syntax error at line 35: `(' unexpected 


A: Your version of HP-UX limits the shell names to very short strings. Upshot is a program that is executed by the wish shell, and for some reason HP-UX is both refusing to execute in this shell and then trying to execute the upshot program using your current shell (e.g., sh or csh), instead of issuing a sensible error message about the command name being too long. There are two possible fixes:
1. Add a link with a much shorter name, for example


ln -s /usr/local/tk3.6/bin/wish /usr/local/bin/wish  

Then edit the upshot script to use this shorter name instead. This may require root access, depending on where you put the link.


2. Create a regular shell program containing the lines


#! /bin/sh 
/usr/local/tk3.6/bin/wish -f /usr/local/mpi/bin/upshot 

(with the appropriate names for both the wish and upshot executables).
Also, file a bug report with HP. At the very least, the error message here is wrong; also, there is no reason to restrict general shell choices (as opposed to login shells).