-
Notifications
You must be signed in to change notification settings - Fork 170
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
gdasearc08 not archiving correctly in bash #1032
Labels
bug
Something isn't working
Comments
WalterKolczynski-NOAA
added a commit
to WalterKolczynski-NOAA/global-workflow
that referenced
this issue
Oct 3, 2022
The group number was being treated as an octal in gdas archive job, resulting in errors for being out-of-range when more than 7 groups were used. Fixes NOAA-EMC#1032
WalterKolczynski-NOAA
added a commit
to WalterKolczynski-NOAA/global-workflow
that referenced
this issue
Oct 3, 2022
The group number was being treated as an octal in gdas archive job, resulting in errors for being out-of-range when more than 7 groups were used. Fixes NOAA-EMC#1032
WalterKolczynski-NOAA
added a commit
to WalterKolczynski-NOAA/global-workflow
that referenced
this issue
Oct 3, 2022
The group number was being treated as an octal in gdas archive job, resulting in errors for being out-of-range when more than 7 groups were used. Fixes NOAA-EMC#1032
WalterKolczynski-NOAA
added a commit
to WalterKolczynski-NOAA/global-workflow
that referenced
this issue
Oct 6, 2022
The group number was being treated as an octal in gdas archive job, resulting in errors for being out-of-range when more than 7 groups were used. Fixes NOAA-EMC#1032
7 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I'm using the current develop branch on Orion with LOCALARCH="YES" and 80 ensemble members to allow for local archiving of tar files (to transfer to Niagara, then HPSS later). gdasarch, gfsarch, and gdasearc00-gdasearc07 all run as expected.
gdasearc08, however, does not archive the appropriate tar files. The following is noted in gdasearc08.log:
/work/noaa/aoml-osse/scasey/fv3develop20220921/global-workflow/jobs/rocoto/earc.sh: line 35: 08: value too great for base (error token is "08")
I have only seen this happen on Orion, but this is the only machine I have access to where I use bash, so it could happen elsewhere.
This occurs with a version of the develop branch checked out 20220921, and can be reproduced with minimal changes to config.base defaults in cycled mode:
CCPP_SUITE="FV3_GFS_v16"
imp_physics=11
NMEM_ENKF=80
HPSSARCH="NO"
LOCALARCH="YES"
ARCH_WARMICFREQ=1
See (on Orion) /work/noaa/aoml-osse/scasey/EXPDIR/test3/config.base for full settings.
In discussion with Kate and Walter, and testing on Orion, it was determined that this group-8 archival issue can be fixed with two changes to earc.sh:
Line 35: n=$((10#$ENSGRP))
Line 65: if [[ 10#$ENSGRP -gt 0 ]] && [[ $HPSSARCH = "YES" || $LOCALARCH = "YES" ]]; then
Without "10#" added before $ENSGRP, bash will interpret any number beginning with 0 as an octal, which only has values 0-7. Adding 10# to the beginning ensures $ENSGRP is treated as a decimal.
The text was updated successfully, but these errors were encountered: