Closed braczka closed 8 months ago
the error message printing the wrong line from the namelist is the intel compiler
see https://github.com/NCAR/DART/issues/578
and the intel forum response: https://community.intel.com/t5/Intel-Fortran-Compiler/backspace-with-namelist-read/m-p/1548510#M169536
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.
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
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
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.
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 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.)
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.
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:
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:I found this error misleading, as the fundamental issue, I believe, is defining the
filter_kind
option inassim_tools_nml
. Once this option is removed andspread_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, iffilter_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.
If user defines
filter_kind
within&assim_tools_nml
in post v11.0.0 DART version, user should be prompted to removefilter_kind
definition and define it through&algorithm_nml
or just leave blank to provide default EAKF algoirthm.User is provided with this error message:
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