bug: reading clamping values entered as integers gives incorrect values

[hkershaw-brown]

🐛 Your bug may already be reported!
Please search on the issue tracker before creating a new issue.

Describe the bug

1. List the steps someone needs to take to reproduce the bug.
   Give a string integer value for clamping in a namelist, e.g '-2'
2. What was the expected outcome?
   The clamping value would be read as -2
3. What actually happened?
   The clamping value is read as 2e-8

Error Message

Please provide any error messages.
No error just wrong values for clamping

Which model(s) are you working with?

MOM6 - editied for clamping!
But I believe this affects any module using the default parse variables clamp and any model using formatted '(d16.8)' read of a string.
e.g wrf

DART/models/wrf/model_mod.f90

Line 7824 in e08756e

read(bound_trim,'(d16.8)') lb

mpas

DART/models/mpas_atm/model_mod.f90

Line 4165 in e08756e

read(bound,'(d16.8)') lower_bound

Screenshots

If applicable, add screenshots to help explain your problem.

Here is the test_parse_variables with some integers in the namelist.

 --------------------------------------
 Starting ... at YYYY MM DD HH MM SS = 
                 2025 12 11 12 35 55
 Program test_parse_variables
 --------------------------------------

  set_nml_output No echo of NML values
1..28
ok 1 
ok 2 
ok 3 
ok 4 
ok 5 
ok 6 
ok 7 
ok 8 
ok 9 
ok 10 
ok 11 
ok 12 
ok 13 
ok 14 
ok 15 
ok 16 
ok 17 
ok 18 
ok 19 
ok 20 
ok 21 
ok 22 - 1.0 
 values   1.0000000000000000     
not ok 23 - integer '2' 
 values   2.0000000000000000E-008
not ok 24 - integer '-4' 
 values  -4.0000000000000001E-008
not ok 25 - integer '3' 
 values   2.9999999999999997E-008
ok 26 
ok 27 
ok 28 

 --------------------------------------
 Finished ... at YYYY MM DD HH MM SS = 
                 2025 12 11 12 35 55
 --------------------------------------

Version of DART

Which version of DART are you using?
You can find the version using git describe --tags
v11.19.1-1-gb0378317e

Have you modified the DART code?

Yes
If your code changes are available on GitHub, please provide the repository.
Here you go, changing the test_parse_variables.f90 to test integer inputs:
main...read-str

Note to self, don't just happy path test.

Build information

Please describe:

1. mac m
2. The compiler you are using (e.g. gnu, intel).
   GNU Fortran (MacPorts gcc13 13.3.0_2+stdlib_flag) 13.3.0
   Copyright (C) 2023 Free Software Foundation, Inc.

I have not tested intel or other compilers yet. I think this is fortran standard to scale an integer like this:

https://j3-fortran.org/doc/year/18/18-007r1.pdf

NOTE 1
If the input field does not contain an exponent, the effect is as if the basic form were followed by an exponent
with a value of −k, where k is the established scale factor (13.8.5).

[hkershaw-brown]

affects any string read

[hkershaw-brown]

wrf, mpas, tiegcm use d16.8
https://github.com/search?q=repo%3ANCAR%2FDART%20d16.8&type=code