I've got a dataset of FSDS from E3SM that's on the ne30pg2 grid that I'm regridding to finite volume 1 degree via "ncremap" and the only version that I've tested that works is NCO 5.0.1 as installed at NERSC.
Other versions (4.7.4, 4.7.9, 4.9.5, 5.0.3, 5.1.0) create an output FSDS file that's got the moire-like pattern of an incorrect regridding.
output
/glade/scratch/strandwg/v2_regrid/FV1_FSDS.nc
(good, created on cori.nersc.gov with /global/common/software/spackecp/cori/e4s-22.02/software/cray-cnl7-haswell/gcc-11.2.0/nco-5.0.1-clkqcrshmdwsfmovawgfs3br5us3gdvd/bin/ncremap)
Hi Gary,
Thanks for reporting this. This is likely due to a recently fixed (in NCO 5.1.4 in January) issue. I encourage you to re-try with 5.1.4 (e.g., from conda-forge via conda install -c conda-forge nco, or from ~zender/[bin,lib]) on finer computers everywhere. In fact, as you may suspect, this issue is not widespread. It is only known to occur with NCO compiled with certain switches on certain architectures. It is your bad luck that you have been relying on binaries compiled with the unlucky switches. E3SM folks never noticed this issue for a long time because they mainly get NCO from Conda or from my directories. Every ncremap has worked well when compiled without the unfortunate Spack switches. As I said, I think 5.1.4 finally fixed the underlying problem (a SIMD compiler pragma that works fine with many compilers and architecture, and fails with certain combos). And all earlier versions work if you get them from Conda forge or build them yourself or ... Here's some proof that the executables I maintain on Cheyenne do the right thing. The below lines show that global mean FSDS agrees with your good version:
I was unaware that the NERSC NCO modules suffered from this issue, so I'll ask them to rebuild with 5.1.4. LMK if these suggestions do not work for you. Thanks again for alerting me to this.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've got a dataset of FSDS from E3SM that's on the ne30pg2 grid that I'm regridding to finite volume 1 degree via "ncremap" and the only version that I've tested that works is NCO 5.0.1 as installed at NERSC.
Other versions (4.7.4, 4.7.9, 4.9.5, 5.0.3, 5.1.0) create an output FSDS file that's got the moire-like pattern of an incorrect regridding.
Data are at casper.ucar.edu
input
/glade/scratch/strandwg/v2_regrid/LR_FSDS.nc
output
/glade/scratch/strandwg/v2_regrid/FV1_FSDS.nc
(good, created on cori.nersc.gov with /global/common/software/spackecp/cori/e4s-22.02/software/cray-cnl7-haswell/gcc-11.2.0/nco-5.0.1-clkqcrshmdwsfmovawgfs3br5us3gdvd/bin/ncremap)
/glade/scratch/strandwg/NCAR_FV1_FSDS.nc
(incorrect)
Same mapping file map_ne30pg2_to_fv0.9x1.25_aave.20220202.nc was used.
Thanks!
Hi Gary,
Thanks for reporting this. This is likely due to a recently fixed (in NCO 5.1.4 in January) issue. I encourage you to re-try with 5.1.4 (e.g., from conda-forge via
conda install -c conda-forge nco
, or from~zender/[bin,lib])
on finer computers everywhere. In fact, as you may suspect, this issue is not widespread. It is only known to occur with NCO compiled with certain switches on certain architectures. It is your bad luck that you have been relying on binaries compiled with the unlucky switches. E3SM folks never noticed this issue for a long time because they mainly get NCO from Conda or from my directories. Every ncremap has worked well when compiled without the unfortunate Spack switches. As I said, I think 5.1.4 finally fixed the underlying problem (a SIMD compiler pragma that works fine with many compilers and architecture, and fails with certain combos). And all earlier versions work if you get them from Conda forge or build them yourself or ... Here's some proof that the executables I maintain on Cheyenne do the right thing. The below lines show that global mean FSDS agrees with your good version:I was unaware that the NERSC NCO modules suffered from this issue, so I'll ask them to rebuild with 5.1.4. LMK if these suggestions do not work for you. Thanks again for alerting me to this.
Thanks, Charlie!