Unbound variable (RSTDIR_ATM) in forecast_det.sh (minor bug) #1140
Comments
|
@DavidHuber-NOAA, It looks to me the description is point to a different file. Please update and confirm this issue. The file in question should be forecast_det.sh. Line number for the logic in question is 43. |
|
@lgannoaa You are correct that the file is forecast_det.sh and the line in question is 43. This is what is stated in the description under "Current behavior". I also mention that the variable is created in forecast_predet.sh. I felt this was relevant information as it is apparent in forecast_predet.sh that the variable should only be used during GDAS forecasts. Apologies if this caused confusion. |
|
@DavidHuber-NOAA , I have a file ready for you to test. Please let me know if it looks good for you, so I can create PR for it. |
|
@lgannoaa the changes look good to me. Thanks! |
The forecast was attempting to check `RSTDIR_ATM` for restart files, but that variable is not defined for gdas, resulting in an unbound variable error. Because the error occurred in a subshell, the error had no impact on the execution, just an unwanted error message in the log. Now that directory is only checked when the `$CDUMP` is 'gfs'. Also fixes some linter warnings. Fixes #1140
Undoes the portion of PR #1179 that caused a new bug while attempting to fix #1140, without removing the linter fixes. Instead `/dev/null` is 'searched' if `${RSTDIR_ATM}` is not defined. That situation will always result in zero files found, ensuring a rerun is not triggered. Fixes #1140 Fixes #1185 Moots #1190
Your bug may already be reported!
Please search on the Issue tracker before creating one.
Expected behavior
FV3_GFS_det should run without error when called during gdasfcst jobs.
RSTDIR_ATMis only a required variable for gfsfcst jobs (set in forecast_predet.sh:212) and should not be referenced.Current behavior
RSTDIR_ATMis referenced during both gdas and gfs fcst steps, resulting in an unbound error at forecast_det.sh:43 during gdasfcst. It appears that this unbound error only affects thefindcommand within the command substitution and so flow continues withfilecount=0, which does not affect on the remainder of the function. I'm not sure if this is the usual/constant behavior whenset -uis toggled.Machines affected
Found on Google Cloud.
To Reproduce
Run a gdasfcst job and check the resulting log.
Possible Implementation
Replace
filecount=$(find $RSTDIR_ATM -type f | wc -l)with
[[ $CDUMP = "gfs" ]] && filecount=$(find $RSTDIR_ATM -type f | wc -l)or
remove
$CDUMP = "gfs"from the proceedingifand move thefilecountassignment and the proceedingifinto a newif [ $CDUMP = "gfs" ]; thenblock.The text was updated successfully, but these errors were encountered: