ufs-community / ccpp-physics

UFS fork for CCPP
Other
4 stars 33 forks source link

missing type-kind in module_nst_water_prop.f90 #125

Closed DeniseWorthen closed 10 months ago

DeniseWorthen commented 11 months ago

The module interfaces for sw_ps_9b and sw_ps_9b_aw lack definitions for the kind of the input arguments. This works fine for UWM (the default type for real variables is set in the compile (-real-size 64)).

https://github.com/ufs-community/ccpp-physics/blob/3855dccfe68750b7681adc32de2c6cf2abe689d9/physics/module_nst_water_prop.f90#L120-L142

I was attempting to compile this module from inside CMEPS however, which does not specify a default. It failed with

There is no matching specific subroutine for this generic subroutine call.   [SW_PS_9B]

Specifying kind=kind_phys in the required interfaces should not have any impact on current UWM RTs. However, testing found that two tests did in fact fail with this change:

hafs_regional_atm_wav_intel
atmwav_control_noaero_p8_intel

Both tests ran to completion but failed in the comparison of only the (binary) wave restart file:

[Hera: hfe03] /scratch1/NCEPDEV/nems/Denise.Worthen/WORK/ufs_dev/tests: grep NOT logs/RegressionTests_hera.log
4862: Comparing ufs.hafs.ww3.r.2019-08-29-21600 .........NOT OK
5793: Comparing ufs.atmw.ww3.r.2021-03-22-64800 .........NOT OK
dustinswales commented 11 months ago

@DeniseWorthen Good catch. Yeah this looks like a problem. It may be that these intrinsics need to always be kind=kind_dbl_phys, not kind=kind_phys?

DeniseWorthen commented 11 months ago

@dustinswales All the other remaining declarations in that module are kind_phys, so I was assuming that would be the fix.

DeniseWorthen commented 11 months ago

Also, I have to admit I don't understand how the 32BIT ifdef interacts w/ the -real-size 64