will wieder

From an email with @jedwards4b , Using weights file `/glade/campaign/cesm/cesmdata/inputdata/cpl/gridmaps/ne30pg3/map_ne30pg3_to_1x1d_aave.nc` And a bilinear technique from esmf. The code is in `/glade/work/cmip7/e3sm_to_cmip/e3sm_to_cmip/cmor_handlers/regrid_se.py`

Also my response over email: Great thanks Jim. A few thoughts. I got better results using the conservative regridding approach for land variables. I also found that I needed to...

From conversation with @olyson and @slevis-lmwg today: - **Keith** will try using ncremap to do this too: - **Will** can try his script and compare all of the above -...

I think @olyson used this weight file `/glade/campaign/cesm/cesmdata/inputdata/cpl/gridmaps/ne30pg3/map_ne30pg3_to_1x1d_aave.nc`. It looks like this file uses *ESMF_regrid_method = "First-order Conservative"*, with means that ncreamap would also be conservative? It does seem like...

Thanks, I'll take a look this week.

Hey Jim. Global quantities seem poorly conserved with the regridding. Below is the global weighed sum of the flux from the raw data (ne30 in blue) vs. the regridded flux...

OK, I think the areas on the regular grid are likely wonky. I wouldn't expect this on a regular grid, would you?

It seems like the script must just be regridding the ne30 area to the regular grid, which doesn't seem to be working as intended, but your have a way to...

Thanks for jogging my memory, @billsacks. I think you're right we did regrid landfrac from the source to destination grid, as @jedwards4b is doing in his script. I think the...

**Good news:** area looks more like I expected **Bad news:** global quantities are still not being conserved It seems like you're multiplying history variables by the source (ne30) land frac...