gfortran float to integer type conversion problems

[sit23]

Description

When running with gfortran @daw538 have had various nml errors of the type:

FATAL from PE 0: check_nml_error in fms_mod: Unknown namelist, or mistyped namelist variable in namelist main_nml, (IOSTAT = 5010 )

Upon a bit of digging, this is happening when you set variables in the namelist as floats when Isca's fortran expects them as integers. E.g. if you set seconds in main_nml to a float in the python script then Isca will error with gfortran because seconds is expected to be an integer.

When running with the Intel compilers this does not cause an error. It seems that gfortran is a bit fussier about this type of type conversion.

The solution to this is tricky to think about, as it would require the python to know about the fortran types in order to catch this sort of error. Just putting it here to note for anyone with this issue, and so that we can discuss potential work-arounds sometime.

[daw538]

Yes, it's definitely going to need some consideration.

The type error listed above wasn't the only one that @sit23 and I had to change in order to get the code to run successfully, and it's not necessarily immediately obvious where the integer/float traps in the namelist may lie. Whilst one could perhaps argue it is logical for main_nml:seconds to be an integer as it relates to the frequency of data output, one of the other fixes related to the construction of the saturation vapour table in sat_vapor_pres_nml. To me at least there's no reason logically why the limits of the table would need to be integers.

Two possible methods come to mind with regards to catching these errors (that's not to say either would be any good):

1. Create a list/database file of all the numeric namelist variables that exist in the model (or at least the most common ones), and python cross-references with this when converting the python namelist to a fortran version for the model, throwing an appropriate error when needed. I have no idea how many variables would fall under this, and finding them feels like it would be a more manual process?
2. A more sophisticated method perhaps (I don't know if it is possible) would be for an automatic look-up of the fortran variable types within the source code itself when the python script is submitted, and then this is fed back and any errors are caught. Feels like this would be more elegant but a lot more work to implement?

[sit23]

Just to note that this issue also arises for the ape_aquaplanet test case. Both dt_rad and solday are floats in the python, and this causes the script not to run. Note to self here to fix that.