bug: formatted write too long for specified number of characters

[hwreeves-USGS]

I ran into an error in formatted write for a MT3D-USGS SSM file.
Flopy is using util_list.py, write_transient() function to
generate the package.

For large values, the writing using %10G format does not stay in
10 characters:

    92         0 # stress period 20
     1        63       253    604784        15
     1        63       254    604784        15
     1        63       255    604784        15
     1        63       256    604784        15
     1        64       252    604784        15
     1        64       253    604784        15
     1        64       254    604784        15
     1        64       255    604784        15
     1        64       256    604784        15
     1        64       257    604784        15
     1        65       252    604784        15
     1        65       253    604784        15
     1        65       254    604784        15
     1        65       255    604784        15
     1        65       256    604784        15
     1        65       257    604784        15
     1        66       252    604784        15
     1        66       253    604784        15
     1        66       254    604784        15
     1        66       255    604784        15
     1        66       256    604784        15
     1        66       257    604784        15
     1       125       2041.21784E+06        15
     1       125       2051.21784E+06        15
     1       126       2041.21784E+06        15

The exponential is not read correctly by MT3D-USGS,
so the specified loading is taken as
1.21784 and the source type is wrong to the output file.
MT3D-USGS is not throwing an error. Note that flopy throws and
error when trying to read this file back in because it
is getting '6 1' where it expects an integer.

If the specification for ftm_string property is updated in flopy util_list.py
elif vtype == "f":
if use_free:
fmts.append("%15s")
else:
fmts.append("%10G")

is updated to
elif vtype == "f":
if use_free:
fmts.append("%15s")
else:
fmts.append("%10.4G")

then the input file looks OK.

    92         0 # stress period 20
     1        63       253 6.048E+05        15
     1        63       254 6.048E+05        15
     1        63       255 6.048E+05        15
     1        63       256 6.048E+05        15
     1        64       252 6.048E+05        15
     1        64       253 6.048E+05        15
     1        64       254 6.048E+05        15
     1        64       255 6.048E+05        15
     1        64       256 6.048E+05        15
     1        64       257 6.048E+05        15
     1        65       252 6.048E+05        15
     1        65       253 6.048E+05        15
     1        65       254 6.048E+05        15
     1        65       255 6.048E+05        15
     1        65       256 6.048E+05        15
     1        65       257 6.048E+05        15
     1        66       252 6.048E+05        15
     1        66       253 6.048E+05        15
     1        66       254 6.048E+05        15
     1        66       255 6.048E+05        15
     1        66       256 6.048E+05        15
     1        66       257 6.048E+05        15
     1       125       204 1.218E+06        15
     1       125       205 1.218E+06        15

I didn't submit it as a pull request in case this change might
cause problems for other cases. I've only tested this
on Windows but can check if the same happens for linux
if that is helpful.

[wpbonelli]

@hwreeves-USGS a pull request is welcome. the CI tests can give us a hint whether this is safe. It looks like an improvement on the current situation at least. Thanks for reporting.

[wpbonelli]

The problem with specifying the number of digits is we lose precision in cases like

>>> "{:10.5G}".format(1.000005)
'         1'

(I found that not only 4 but %10.5G fits in 10 chars even for huge/tiny numbers)

This is a surprisingly hard problem to solve. Python doesn't seem to have a way to flexibly (i.e. switching between fixed/scientific) format a real to fit in a fixed width with the maximum possible precision.

We could put some code in to try the G format, see if it overruns, then fall back to something else. But that seems like a hack. I'm not sure what the right answer is here.

[mwtoews]

A while ago I was investigating a method to maximize precision in a fixed character width, as required by MT3D-USGS. Perhaps I can dust this method off, as it was nearly complete but not contributed to anywhere publicly.

[wpbonelli]

I was wondering if the strategy in #2658 could be relevant here but looking at the MT3D docs I guess it isn't, since free format isn't supported for the SSM package's loading rate..