UMDP3 checker incorrectly identifies .....

[r-sharp]

This is a location for documenting either false failure flags or missing failure flags from the UMDP3 checker.
It is intended to inform the follow on PR from #234

At the time of writing, the only false failures spotted so far ar the incorrect labelling of the variable 'long' as a deprecated intrinsic. Given that variable names shouldn't be the same as intrinsics anyway, this is morst likely to require a change top the UM's code, but is listed here in case a solution at this end materializes.

[t00sa]

This is a false positive:

✗ FAIL  file : um/src/atmosphere/gravity_wave_drag/g_wave5a.F90
    --------------------------------------------------------------------------------------
     Unseparated Keywords                                         : Found   1 failure.
        ----------------------------------------------------------------------------------
         1 : unseparated keyword in line: REAL(KIND=real_umphys), INTENT(IN OUT) ::                &!intent(inout): : [237]
        ----------------------------------------------------------------------------------

The bit of code responsible is as follows and removing the comment after the continuation character makes the problem go away:

REAL(KIND=real_umphys) ::               &!intent(inout):
  r_u(udims_s%i_start:udims_s%i_end,    & !u wind increment diagnostic

[t00sa]

Preprocessor macros are being picked up as lowercase or unseparated keywords:

✗ FAIL  file : um/src/io_services/common/geometry/ios_model_geometry.F90
    --------------------------------------------------------------------------------------
     Capitalised Keywords                                         : Found   1 failure.
        ----------------------------------------------------------------------------------
         1 : lowercase keyword: if : [262]
        ----------------------------------------------------------------------------------
     Unseparated Keywords                                         : Found   1 failure.
        ----------------------------------------------------------------------------------
         1 : unseparated keyword in line: #endif : [270]
        ----------------------------------------------------------------------------------

Relevant section of code is:

#if !defined(CPP_IOS_STATIC_DATA)
! Allocate sendbuffers.
DO ibuf=1,IOS_AsyncNumSlots
  ALLOCATE(slot(ibuf)%buffer (MaxFieldDomain*IOS_AsyncMaxFieldsInPack))
  ALLOCATE(slot(ibuf)%control(                                                 &
      ios_max_cntrlwords_per_field *                                           &
      IOS_AsyncMaxFieldsInPack))
END DO
#endif

[t00sa]

Also, I'm not sure if this is a false positive or not: a comment line over 80 characters getting picked up as a long line.

[t00sa]

I think this is a known bug where .TRUE. or .FALSE. trips up the uppercase variable checker, e.g. in um/src/atmosphere/dynamics/conservation_diag_mod.F90

LOGICAL, PARAMETER :: initial_timestep = .TRUE.
LOGICAL, PARAMETER :: not_initial_timestep = .FALSE.

This also causes false positives:

INTEGER, PARAMETER :: defaultsize = BIT_SIZE(0)/8

Also:

INTEGER, POINTER     :: atm_global_points(:,:)=>NULL()

[t00sa]

This one is just a diagnostic message mismatch - the error reported is UPPERCASE variable name even though the variable is mixed case:

REAL, INTENT(IN OUT) :: STASHwork14(:)   ! STASH workspace

[t00sa]

A possible solution to both the .TRUE. etc problem and the camel case one - although, in this definition variables like FOO_BAR_BAZ are accepted, which might not be what we want.

The change to lowercase_variable_names() in umdp3_checker_rules.py is as follows:

clean_line = re.sub(
    r"^\s*(INTEGER|REAL|LOGICAL|CHARACTER|TYPE)\s*.*::\s*",
    "",
    clean_line,
)

# Remove everything after any equals sign
clean_line = clean_line.split("=")[0]

if re.search(r"\b(?>[A-Z]{2,})(?![_\w]+)", clean_line):
    self.add_extra_error("UPPERCASE variable name")
    failures += 1
    error_log = self.add_error_log(
        error_log, "UPPERCASE variable name", count + 1
    )

It strips off everything after an = sign to deal with logicals, functions, null pointers etc, and then uses a pattern which matches something that starts with two upper case characters and, if that matches, only matches if it is not followed by an underscore or a word character. This seems to work in most - all? - cases. The only snag is that the (?>...) syntax requires python 3.11.