Parsing of scientific notation in IN file

[jonmaddock]

In GitLab by @timothy-nunn on Apr 5, 2023, 17:36

I am getting an interesting error when experimenting with new VMCON which forces initial values of iteration variables to be greater than or equal to their lower bound (and upper bound). The following keeps occuring:

gapoh (for example) will be enabled as an iteration variable with some bounds set in the IN file

ixc = 42 * gapoh
boundl(42) = 0.05
boundu(42) = 0.1

Next gapoh will be set in the IN file, and the last time it is set will look as follows

gapoh          =  5.0000E-02

New VMCON will throw an error claiming gapoh is below its lower bound. This error is fixed by setting the above line to its equivalent decimal notation

gapoh          =  0.05

This suggests some weird rounding may be occurring when parsing the scientific notation which causes the value to become ever so slightly greater than 0.05, on the floating point level.

[timothy-nunn]

Able to replicate for large-tokamak using

* TF coil conduit thickness [m]
ixc = 58
boundl(58) = 0.008
*thwcndut = 0.008
thwcndut = 8.0000E-03

HOWEVER
The following shell output shows that it is, in fact, the decimals that are not rendered properly:

(Pdb) p fortran.numerics.boundl[57]
0.008000000000000002
(Pdb) p fortran.tfcoil_variables.thwcndut
array(0.008)

(changing the bound into scientific notation)

(Pdb) p fortran.numerics.boundl[57]
0.008

[timothy-nunn]

In parse_real_variable printing the value of thwcndut shows that the non-scientific notation 0.008 is parsed slightly differently:

 thwcndut-pre:::::::   8.0000000000000002E-003
 thwcndut-post::::::   8.0000000000000019E-003