remove all source code and build system references to SGITFP, which is an obsolete platform.
SGI_N32 is next, which is closely related.
Signed-off-by: Jeff Hammond <jeff.science@gmail.com>
as to how the restart file should be handled. I have added some documentation
specifying the state of the restart file when routines operating on it
return.
1. The subroutine STPR_PUT_GENAT_RESTART had the peculiar behavior
of deleting the restart file before opening it with STATUS="NEW".
The disadvantage of this was that incase anything went wrong with
the OPEN statement the restart data is distroyed and the calculation
needs to be rerun from the beginning. (Also not all runtimes take
kindly to deleting files that you are still using, see next point).
It seems that the reason for deleting the file is opening it with
STATUS="NEW" which causes modern runtimes to abort the calculation
if the file already exists. Of course the file could be opened with
STATUS="UNKNOWN" but if you try and open a file that is already open
then the file position remains where it is, whereas if the file
was not open you could be sure that after the open statement the
file position is at the beginning. This creates the difference
between overwriting the restart data (the intended result) versus
appending the restart data.
None of this kind of trouble would occur if every routine
interacting with the restart file did this correctly. I.e. OPEN the
file, do what you need to do, and CLOSE the file. If this practice
is adhered to then the file should be closed when entering
STPR_PUT_GENAT_RESTART.
* The first fix is to check that the file is actually closed and if
not detect that as a fatal error because fundamental assumptions
are violated.
2. The subroutine STPR_GET_GENAT_RESTART would open the restart file
and read it. But the file was closed only when the restart file was
incompatible with the current calculation. If the restart file was
OK then the data would be read until the end but the file never
closed (hence, most likely, the weird stuff going on in
STPR_PUT_GENAT_RESTART). This caused problems on Cascade with the
Intel compilers in that the restart file got deleted and then
code crashed with I/O errors like:
unexpected disconnect completion event from [0:g232]
and
forrtl: severe (104): incorrect STATUS= specifier value for
connected file, unit 69, file <some file>.fdrst
These problems disappeared when the UTIL_FILE_UNLINK call was
removed.
* The second fix is the close the restart file when we are done
reading it.
they are overriden by TASK OPTIMIZE and TASK SADDLE. This can lead to
confusing outcomes (like error messages that point to issues that are
unrelated to the actual problem). A few small modifications were made
to allude to the what is really happening in the code.
automatically be expanded to include useful information about the
checkin (including the file's revision number). With the switch over
to SVN this was lost because SVN only does this expansion if you
explicitly ask for it (for every single file).
I have added a script to the contrib directory that sets the appropriate
property to get SVN to do this expansion. This script will make it easy
to do this every time new source files are added. It is called
svn_expand_Id, the script contains some comments that explain the issue
and how it addresses this.
This checkin sets this property for a subset of the relevant files
(trying to commit all files at once failed with svn crashing).
In future the script will only affect those files for which the property
was not set before.
