Brian,
If the Netcdf Fortran 77 and 90 interfaces emulated normal Fortran
string assignment rules, then your issue would probably be moot
because any string passed to nf90_put_var_text would be padded with
right hand blanks, as needed, to fill the allocated string length in
the file. This is my preferred solution.
Otherwise I agree that the current behavior of nf90_put_var_text for
a scalar string is a problem. I wonder what the original rationale
was for that, or whether it was just an oversight.
This reminds me of the nf90_put_att function with strings, which
uses the blank-trimmed length to nicely accomplish variable length
text attributes. But it does not make sense for a pre-allocated
Netcdf variable.
Dave Allured
CU/CIRES Climate Diagnostics Center (CDC)
http://cires.colorado.edu/science/centers/cdc/
NOAA/ESRL/PSD, Climate Analysis Branch (CAB)
http://www.cdc.noaa.gov/psd1/
Brian Eaton wrote:
Hi All,
I have discovered (the hard way, of course) that the Fortran 90 interface
nf90_put_var treats scalar strings in an unexpected way. The specific
function for writing a scalar string is nf90_put_var_text (in
netcdf_text_variables.f90) and this function uses the len_trim intrinsic to
compute count, and uses the trim intrinsic in the call to nf_put_vars_text.
This strips the trailing blanks that fortran codes depend on. If the
default prefill is on then the application that reads the string gets
trailing nulls rather than blanks which is not too hard to deal with.
However, if prefill is turned off, which is the normal mode of operation
for models writing large datasets, then the reading application gets
trailing garbage which is a disaster.
The specific interface for scalar strings is the only one that does this;
arrays of strings are treated properly.
I consider it a bug that the F90 interface alters the data passed by the
user to be written to the file. I'm interested to hear whether there are
other points of view about this behavior.
Thanks,
Brian
