Gnu MCT builds will fail starting in ctsm5.1.dev113

[billsacks]

Brief summary of bug

Starting in ctsm5.1.dev113, Gnu builds with the MCT driver are expected to fail. Since the MCT driver is deprecated, we do not plan to fix this issue.

General bug information

CTSM version you are using: ctsm5.1.dev113

Does this bug cause significantly incorrect results in the model's science? No

Configurations affected: Gnu builds with the MCT driver

Details of bug

The build fails when compiling clm_time_manager.F90 with errors like this:

/home/sacks/ctsm_code/ctsm/src/utils/clm_time_manager.F90:12:26:

   12 |    use ESMF        , only: operator(>), operator(<), operator(-)
      |                          1
Error: Intrinsic operator ‘>’ referenced at (1) not found in module ‘esmf’
/home/sacks/ctsm_code/ctsm/src/utils/clm_time_manager.F90:12:39:

   12 |    use ESMF        , only: operator(>), operator(<), operator(-)
      |                                       1
Error: Intrinsic operator ‘<’ referenced at (1) not found in module ‘esmf’
/home/sacks/ctsm_code/ctsm/src/utils/clm_time_manager.F90:11:53:

   11 |    use ESMF        , only: operator(==), operator(+), operator(<=), operator(>=)
      |                                                     1
Error: Intrinsic operator ‘<=’ referenced at (1) not found in module ‘esmf’
/home/sacks/ctsm_code/ctsm/src/utils/clm_time_manager.F90:11:67:

   11 |    use ESMF        , only: operator(==), operator(+), operator(<=), operator(>=)
      |                                                                   1
Error: Intrinsic operator ‘>=’ referenced at (1) not found in module ‘esmf’
/home/sacks/ctsm_code/ctsm/src/utils/clm_time_manager.F90:1715:12:

 1715 |     nstep = step_no
      |            1
Warning: Possible change of value in conversion from INTEGER(8) to INTEGER(4) at (1) [-Wconversion]
/home/sacks/ctsm_code/ctsm/src/utils/clm_time_manager.F90:785:16:

  785 |     get_nstep = step_no
      |                1
Warning: Possible change of value in conversion from INTEGER(8) to INTEGER(4) at (1) [-Wconversion]
/home/sacks/ctsm_code/ctsm/src/utils/clm_time_manager.F90:620:12:

  620 |     nstep = step_no
      |            1
Warning: Possible change of value in conversion from INTEGER(8) to INTEGER(4) at (1) [-Wconversion]
/home/sacks/ctsm_code/ctsm/src/utils/clm_time_manager.F90:279:9:

  279 |     if ( stop_date <= start_date ) then
      |         1
Error: Operands of comparison operator ‘<=’ at (1) are TYPE(esmf_time)/TYPE(esmf_time)
/home/sacks/ctsm_code/ctsm/src/utils/clm_time_manager.F90:287:9:

  287 |     if ( stop_date <= curr_date ) then
      |         1
Error: Operands of comparison operator ‘<=’ at (1) are TYPE(esmf_time)/TYPE(esmf_time)
/home/sacks/ctsm_code/ctsm/src/utils/clm_time_manager.F90:306:14:

  306 |     do while( curr_date > current )
      |              1
Error: Operands of comparison operator ‘>’ at (1) are TYPE(esmf_time)/TYPE(esmf_time)
gmake: *** [clm_time_manager.o] Error 1

[billsacks]

Closing as a wontfix since mct is deprecated.

[billsacks]

@ekluzek points out that you can probably workaround this issue with:

./xmlchange USE_ESMF_LIB=TRUE

before building (I haven't tested this).

[ekluzek]

I looked into this a tiny bit and I think the difference is that the WRF time-manager defines the operators using the FORTRAN form .EQ., .LT. and the like, whereas the full ESMF defines using the symbolic form ==, <, etc. I'm guessing when you don't use the only clause and with most compilers, it can reconcile the difference, but GNU is failing for this case when the form doesn't match exactly.

As such we could fix this, but we shouldn't with MCT going away. And it should work with using the full ESMF library. That actually could be a nice stepping stone for people to move over to NUOPC, start using MCT but use the full ESMF library. Using the full ESMF library is a requirement for NUOPC, so you have to get it setup to make the switch anyway.