Backslash escapes

[Dave Offiler]

Torben Schmidt (GFZ) reports that v4.0 gfz2ropp tool crashes when converting TerraSAR-X and GRACE-A native files to ROPP netCDF. He found the problem to be:

removing "\n" in line 595 of gfz2ropp.f90 has solved the problem.

With the following function call

CALL message ( msg_info, "Writing " // TRIM(opfile) ) the program is running without problems

He is compiling with gfortran, so I've suggested trying the -fbackslah option. As we have successfully tested this tool with gfortran 'out of the box' on both MetO RHEL4 and personal OpenSUSE and Cygwin without explicitly setting this flag, this is a bit of a mystery. Need to check with Torsten which version of gfortran he's using - may be for new versions (v4.4.x) like ours, -fbackslash is default but for his is not (TBC).

In any case, '\n' or any similar escape sequences are rather foreign to F90 so we should review whether simple newlines can be passed to ropp_message by some alternative flag, or just break the message into multiple subroutine calls.

This problem can potentially affect any ROPP code using the message routines, so needs to be reviewed as a general issue.

[Dave Offiler]

Reading the man page for gfortran more carefully, -fbackslash seems to do the opposite of ifort's -nbs, in that the default is to leave '\' in strings as a literal backslash, but -fbackslash converts the usual '\n'\, '\t' etc sequences to the C-style newline, tab, equivalents. So I don't think this option will do anything (and might make things worse!)

Now checking with Torsten which version of gfortran he's compiling with; an older version than our v4.4.0 (which runs perfectly well with sample test files) may have a different default behaviour for backslashes...

[Dave Offiler]

No reply from Torsten as yet.

Meanwhile, I've deleted the '\n' from the string that caused the immediate problem at GFZ (changeset [2563]), although I can't reproduce it here with our gfortran v4.4.0.

There are still '\n's in gfz2ropp.f90 but or either commented out or would only be used on an error occurring. This change will at least allow the v4.1 tool to run nominally at GFZ without the source code having to be edited again, but the underlying cause still needs further investigation prior to ROPP-5, so leaving this Ticket open until more info from Torsten.

[Dave Offiler]

No further reply from Torsten. He indicated that the original problem had been fixed, and a number of other \n occurrences (which did not apparantly cause a similar problem) have been removed. Closing this Ticket as fixed.