Skip to content

Bad logic statement in strdata_interface_mod.F90 #68

@mnlevy1981

Description

@mnlevy1981

Description of the issue:

@matt-long tried to add a new forcing field to MARBL and have POP read it in through shared stream, but logic in strdata_interface_mod::POP_strdata_type_match() caused POP to ignore the fact that the field was in a different file and instead was appending the new field to the list of variables read from the stream providing NDEP forcing (which is bad, because the new field doesn't exist there).

Basically,

    POP_strdata_type_match = &
      strdata_input_var1%file_name     == strdata_input_var2%file_name  .and. &
      strdata_input_var1%year_first    == strdata_input_var2%year_first .and. &
      strdata_input_var1%year_last     == strdata_input_var2%year_last  .and. &
      strdata_input_var1%year_align    == strdata_input_var2%year_align .and. &
      strdata_input_var1%depth_flag .eqv. strdata_input_var2%depth_flag .and. &
      strdata_input_var1%tintalgo      == strdata_input_var2%tintalgo   .and. &
      strdata_input_var1%taxMode       == strdata_input_var2%taxMode

is returning True even when strdata_input_var1%file_name and strdata_input_var2%file_name differ. It looks like the solution is to wrap each individual logical statement in parentheses:

    POP_strdata_type_match = &
      (strdata_input_var1%file_name     == strdata_input_var2%file_name)  .and. &
      (strdata_input_var1%year_first    == strdata_input_var2%year_first) .and. &
      (strdata_input_var1%year_last     == strdata_input_var2%year_last)  .and. &
      (strdata_input_var1%year_align    == strdata_input_var2%year_align) .and. &
      (strdata_input_var1%depth_flag .eqv. strdata_input_var2%depth_flag) .and. &
      (strdata_input_var1%tintalgo      == strdata_input_var2%tintalgo)   .and. &
      (strdata_input_var1%taxMode       == strdata_input_var2%taxMode)

behaves as expected.

Version:

  • CESM: this is probably in every version of POP containing strdata_interface_mod.F90; I can track down exactly when this was introduced, but I think it was in the CESM 1.5 or CESM 2.0 development cycle.
  • POP2: We should definitely update main and the POP branch for CESM 2.1; it probably makes sense to patch CESM 2.2 as well, since that's the latest release.

Machine/Environment Description:

This was discovered on cheyenne in CESM 2.2, building with intel

Any xml/namelist changes or SourceMods:

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions