WRF
WRF copied to clipboard
check if USENETCDFPAR is empty first
Otherwise, it spews the following error message when NETCDFPAR is not set by the user.
/bin/sh: line 0: [: -eq: unary operator expected
target is master
@wkliao Please create a complete PR message.
The template for the complete PR message is in .github/PULL_REQUEST_TEMPLATE.
An alternate solution, and the one I chose in #1812, would be to set USENETCDFPAR=0 in configure if NETCDFPAR is not set in the environment, which should be equivalent to the solution here. In either case, leaving USENETCDFPAR unset indicates that the netCDF library is serial, if I understand the documentation in doc/README.netcdf4par.
https://github.com/wrf-model/WRF/blob/21c72141142fc6c8d203d2bf79f1990e45a0aef8/doc/README.netcdf4par#L7-L13
The template for the complete PR message is in
.github/PULL_REQUEST_TEMPLATE.An alternate solution, and the one I chose in #1812, would be to set
USENETCDFPAR=0inconfigureifNETCDFPARis not set in the environment, which should be equivalent to the solution here. In either case, leavingUSENETCDFPARunset indicates that the netCDF library is serial, if I understand the documentation indoc/README.netcdf4par.https://github.com/wrf-model/WRF/blob/21c72141142fc6c8d203d2bf79f1990e45a0aef8/doc/README.netcdf4par#L7-L13
I think the most appropriate solution is to simply initialize USENETCDFPAR to 0 right here
The main issue being that WRF uses USENETCDFPAR to differentiate test type, and the variable is always exported but not initialized. Note that the documentation references NETCDFPAR, not USENETCDFPAR - subtle but quite confusing indeed!
An alternate solution, and the one I chose in #1812, would be to set
USENETCDFPAR=0inconfigureifNETCDFPARis not set in the environment, which should be equivalent to the solution here. In either case, leavingUSENETCDFPARunset indicates that the netCDF library is serial, if I understand the documentation indoc/README.netcdf4par. https://github.com/wrf-model/WRF/blob/21c72141142fc6c8d203d2bf79f1990e45a0aef8/doc/README.netcdf4par#L7-L13I think the most appropriate solution is to simply initialize
USENETCDFPARto 0 right here
That would be cleaner than what I had.
The main issue being that WRF uses
USENETCDFPARto differentiate test type, and the variable is always exported but not initialized. Note that the documentation referencesNETCDFPAR, notUSENETCDFPAR- subtle but quite confusing indeed!
That and some people are used to the current behavior (NETCDF is NETCDFPAR unless explicitly told otherwise), so they treat it as a feature, not a bug.
This PR is more of checking if an environment variable is set and its value if set. The same principle should apply to other environment variables, because an env variable can be 1) not set; 2) set without a value; 3) set with a legal value; and 4) set with an illegal value.
To avoid any confusion, I suggest to discuss the purpose of USENETCDFPAR and NETCDFPAR environment variables in a separate github issue.
@islas The base of this PR was on release 4.5. I just chagned it to 4.5.2. But it looks like it is labeled for develop branch. Should it be left for develop branch? Either way because the base branch is changed, you will need to approve again.
@weiwangncar Definitely 4.5.2 as this is a bug fix.
This PR has passed the regression tests on June 17 2022:
Test Type | Expected | Received | Failed
= = = = = = = = = = = = = = = = = = = = = = = = = = = =
Number of Tests : 23 24
Number of Builds : 60 58
Number of Simulations : 158 156 0
Number of Comparisons : 95 92 0
Failed Simulations are:
None
Which comparisons are not bit-for-bit:
None
@wkliao Wei-keng Liao
Would you please tell where you are working? We need this information for release. Thanks.
@wkliao Wei-keng Liao
Would you please tell where you are working? We need this information for release. Thanks.
I am not clear what you are asking about "where".
@wkliao I mean the research institute/university/company where you are working.
@wkliao I mean the research institute/university/company where you are working.
Northwestern University