bug: Error message when using pre-QCEFF input.nml version

[braczka]

Describe the bug

List the steps someone needs to take to reproduce the bug.

When working on WRF-DART tutorial on Derecho I used a deprecated input.nml version which was not updated in the original QCEFF PR. That is OK -- I will update it as part of new feature and PR associated with #627. Using a deprecated a input.nml template immediately gives a logical error from DART:

  ERROR FROM:
  source : utilities_mod.f90
  routine: find_namelist_in_file
  message:  Namelist entry `&algorithm_info_nml` must exist in file `input.nml`

Prompted by the error, If the user adds the missing namelist entries to input.nml, both &algorithm_info_nml and &probit_transform_nml, and forgets to also remove the filter_kind option within &assim_tools_nml you get the following error:

 ERROR FROM:
  source : utilities_mod.f90
  routine: check_namelist_read
  message:  INVALID NAMELIST ENTRY:    cutoff                          = 0.10, i
 n namelist assim_tools_nml

I found this error misleading, as the fundamental issue, I believe, is defining the filter_kind option in assim_tools_nml. Once this option is removed and spread_restoration = .false., DART runs as would be expected. I think the user should be reminded if they are missing &algorithm_info_nml from their namelist they should also check their &assim_tools_nml options as well to make sure they are updated to QCEFF compatible format. Also, if filter_kind is defined in the &assim_tools_nml the error message needs to be improved.

This error might be quite common given, if a DART user updates their version (post-v11.0.0), but uses an old, deprecated input.nml, and relies on error messages to fix. The quantile methods documentation itself looks OK here.

2. What was the expected outcome?

If user defines filter_kind within &assim_tools_nml in post v11.0.0 DART version, user should be prompted to remove filter_kind definition and define it through &algorithm_nml or just leave blank to provide default EAKF algoirthm.

3. What actually happened?

User is provided with this error message:

 ERROR FROM:
  source : utilities_mod.f90
  routine: check_namelist_read
  message:  INVALID NAMELIST ENTRY:    cutoff                          = 0.10, i
 n namelist assim_tools_nml

Which model(s) are you working with?

WRF4.0

Version of DART

v11.0.1

Have you modified the DART code?

No

Build information

Derecho

1. ncarenv/23.06 (S) 3) intel/2023.0.0 5) cray-mpich/8.1.25 7) netcdf/4.9.2 9) ncl/6.6.2
2. craype/2.7.20 4) ncarcompilers/1.0.0 6) hdf5/1.12.2 8) nco/5.1.4

[hkershaw-brown]

the error message printing the wrong line from the namelist is the intel compiler

see #578

and the intel forum response: https://community.intel.com/t5/Intel-Fortran-Compiler/backspace-with-namelist-read/m-p/1548510#M169536

[braczka]

So intel compiler will always lead to printing incorrect error message? Or this just happens sometimes -- I guess what really threw me is that initial error made sense, whereas wrong line printing on second error was confusing.

[braczka]

Also, if &algorithm_nml and &probit_nml are defined correctly, and filter_kind is removed from &assim_tools_nml, then error message is correct for 'spread_restoration' if not set correctly.

 ERROR FROM:
  source : assim_tools_mod.f90
  routine: assim_tools_init:
  message:  The spread_restoration option is not supported in this version of DA
 RT. Contact the DAReS team if this option is needed

[hkershaw-brown]

Here's the release notes for v11 https://github.com/NCAR/DART/releases/tag/v11.0.0
These also went out to the dart-users email list. You can sign up for the dart-users list here: https://mailman.ucar.edu/mailman/listinfo/dart-users

[hkershaw-brown]

So intel compiler will always lead to printing incorrect error message? Or this just happens sometimes -- I guess what really threw me is that initial error made sense, whereas wrong line printing on second error was confusing.

This version of the compiler prints the incorrect message, seems to be reproducible every time.

[braczka]

So intel compiler will always lead to printing incorrect error message? Or this just happens sometimes -- I guess what really threw me is that initial error made sense, whereas wrong line printing on second error was confusing.

This version of the compiler prints the incorrect message, seems to be reproducible every time.

Just for clarity -- DART documentation is good, and covers how the input.nml should be updated. This is purely an error message question. Agreed this is a intel compiler version issue --but the way that it interacts with DART is not reproducible. Sometimes it gives the 'correct' error message (e.g. &algorithm_nml, spread_restoration), sometimes 'incorrect' DART error message (e.g. filter_kind) -- at least in this case.

At any rate - not a DART bug, so maybe I should have just posted this as a discussion.

[nancycollins]

i took a quick look and unfortunately the fortran "read" routine takes a namelist name and the line-by-line reads are done internally to the compiler. i suppose we could change the error message in our 'check_namelist_read()' routine to say 'either item xxx or the item immediately before' if this compiler bug isn't going to be fixed by intel. (which seems likely - helen reported it and they said it wasn't part of the standard which doesn't sound like anything's going to change.)

[hkershaw-brown]

So intel compiler will always lead to printing incorrect error message? Or this just happens sometimes -- I guess what really threw me is that initial error made sense, whereas wrong line printing on second error was confusing.

This version of the compiler prints the incorrect message, seems to be reproducible every time.

Just for clarity -- DART documentation is good, and covers how the input.nml should be updated. This is purely an error message question. Agreed this is a intel compiler version issue --but the way that it interacts with DART is not reproducible. Sometimes it gives the 'correct' error message (e.g. &algorithm_nml, spread_restoration), sometimes 'incorrect' DART error message (e.g. filter_kind) -- at least in this case.

At any rate - not a DART bug, so maybe I should have just posted this as a discussion.

I wasn't clear with my original comment, Brett
this type of error (namelist &whatever_nml not in the file) works totally ok

  ERROR FROM:
  source : utilities_mod.f90
  routine: find_namelist_in_file
  message:  Namelist entry `&algorithm_info_nml` must exist in file `input.nml`

The type of error message that is incorrect is when the problem occurs with value inside a namelist, that is when is not actually in the code, e.g. filter_kind

&assim_tools_nml
cutoff = 0.2_r8
filter_kind = 1
/

the error message prints out the wrong part of the namelist structure, e.g. cutoff.