Gary Strand

I'm playing around with some raw MPAS ocean data from E3SMv1 and my usual procedure to tranpose the data from output timeslice format to timeseries format is to put each time-dependent field (defined over X, Y, perhaps Z and T) into its own file along with all the fields that are dimensioned only in time (just T), which are usually statistics and analyses that are handy to have in every output file. However, for this particular E3SMv1 run, there are ~230 fields in the MPAS output that are only dimensioned...

I'm trying to regrid some E3SMv2 ocean history files and would like to be able to do a years' worth (12 months) at a time, but it's not clear to me from reading https://acme-climate.atlassian.net/wiki/spaces/DOC/pages/754286611/Regridding+E3SM+Data+with+ncremap How to pass the filenames to "ncremap". Any assistance is most welcome! Thanks.

Thanks, Charlie!

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...

Thanks, Charlie! On Wed, Feb 2, 2022 at 9:25 PM Charlie Zender zender@users.sourceforge.net wrote: Hi Gary, The ncremap regridder produced the moire pattern because the map you gave to it was bad, as can be verified by ncks --chk_map map_ne30pg2_scrip_170608_fv0.9x1.25_scrip_220202.nc After NCO 4.7.9, ncremap switched the default weight generator from ESMF to NCO's internal weight generator which apparently produces a bad map with those two grids. And that sucks for me. However, if you select the...

I have two ne30pg gridfiles, an older one we had here at NCAR - ne30pg2_scrip_170608.nc - I got from Adam Herrington; the newer one is ne30pg2_scrip_20200209.nc, which I got from Oksana Guba. But anyway, thanks for figuring out what's going on. Much appreciated! On Thu, Feb 3, 2022 at 9:48 AM Charlie Zender zender@users.sourceforge.net wrote: ne30pg2 is the default E3SMv2 grid, so the bad map NCO produced was disquieting. Now I understand that the NCO algorithm produced a bad map between ne30pg2...

I'm attempting to regrid some ne30 E3SM data that are on the pg grid to the CESM CAM finite volume 1 degree grid and am only having success with NCO 4.7.9. NCO 4.9.5 and NCO 5.0.3 create incorrect datasets. They look like artifacts of the regridding - a moire pattern is what it looks like. This is on casper.ucar.edu and example data are located under /glade/scratch/strandwg/E3SM The ne30pg2 and FV1 gridfiles and the mapfile are there, as are the input and output datasets. Thanks!

A global field was split into two pieces, one for each hemisphere: ncks -d nj,0,75 infile.nc south.nc ncks -d nj,280,383 infile.nc north.nc Is there a way to rejoin north.nc and south.nc with NCO?