Bug in runoff -> ocean map generator

[mnlevy1981]

The ocean -> ocean smooth map ("step 2" of generating the runoff -> ocean map) maps from a source cell to a collection of destination cells around the source, with an exponential decay as you get farther from the source cell. However, the source cell itself was not included in the destination cells, leaving a hole in the map.

We have a fix for this at NCAR and I will be making a pull request in the coming days.

[rljacob]

Pinging @jonbob

[jonbob]

Thanks @rljacob - I knew about this. But the error is in the smoothing part of that tool, which we can't use because it doesn't support MPAS grids. We have our own internal python tool to smooth the runoff maps, which we have tested extensively.

[mvertens]

I'm wondering in that tool can get put into CIME. It sounds like a more general approach than what we have and it would benefit the wider community to have it in CIME.

On Tue, Mar 14, 2017 at 1:15 PM, Jon Wolfe notifications@github.com wrote:

Thanks @rljacob https://github.com/rljacob - I knew about this. But the error is in the smoothing part of that tool, which we can't use because it doesn't support MPAS grids. We have our own internal python tool to smooth the runoff maps, which we have tested extensively.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ESMCI/cime/issues/1241#issuecomment-286530240, or mute the thread https://github.com/notifications/unsubscribe-auth/AHlxE_flA7R2LY0EdKYcH540ZwnSwhUZks5rludKgaJpZM4MdBBG .

[jonbob]

@mvertens - I'll look at making it more general. Right now, it's just built to understand the MPAS connectivity. But it should be especially easy to extend to structured grids.

[mvertens]

@jonbob - thanks for the clarification. I did not appreciate that.

On Wed, Mar 15, 2017 at 9:42 AM, Jon Wolfe notifications@github.com wrote:

@mvertens https://github.com/mvertens - I'll look at making it more general. Right now, it's just built to understand the MPAS connectivity.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ESMCI/cime/issues/1241#issuecomment-286782934, or mute the thread https://github.com/notifications/unsubscribe-auth/AHlxE7aIdcNJx6HPRjElAEWjk2Cq9yDYks5rmAbjgaJpZM4MdBBG .

[billsacks]

@mnlevy1981 and @mvertens : We also use the runoff -> ocean mapping tool (with smoothing) to generate mapping files from CISM to the ocean - mainly for the sake of routing iceberg discharge. Does this bug imply that we should regenerate all of the CISM -> ocean mapping files once you put the fix in place?

[billsacks]

Another question: Does this bug affect conservation, or only the spatial distribution of the resulting flux?

[mnlevy1981]

@billsacks To answer your two questions:

1. I think you will want to regenerate all your maps, yes. Before you do so, though, talk to @klindsay28 -- he has an NCL script that can plot the following:
   1. a specified runoff grid cell center,
   2. the ocean grid cell closest to the specified runoff cell (nearest neighbor), and
   3. the cells that get mapped from the specified runoff location to the ocean (incorporating the smoothing step). This bug has shown that the nearest neighbor is not included in the smooth map, and you can verify that's the case in your maps as well before recreating them.
2. I don't believe it affects conservation -- conservation is achieved by normalizing the smoothing map, and I'm 99% sure the normalization factor does not include any contribution from the nearest neighbor that was omitted from the smoothing

The only uncertainty is that I did receive a few emails questioning conservation in runoff maps that I need to dig up - if memory serves, a user modified the runoff map tool himself and that's what broke conservation (and we did not bring those modifications onto the trunk)

[jonbob]

@billsacks and @mnlevy1981 - when we played with it here at LANL, thinking about modifying it to use for MPAS grids, I think we decided it was not conserving.

[mnlevy1981]

@jonbob and @billsacks below are output from our check_map utility; it seems like a terrible output decision, but I think the "area" check is actually checking for conservation by integrating the source and destination fields over a unit sphere. This is output from checking the rx1 to gx1v6 runoff map:

 | Need area error <   5.300000000000000E-012  ...
 | PASSED: Area error =   9.237055564881302E-014
 | Need area error <   6.800000000000000E-011  ...
 | PASSED: Area error =   5.293543381412746E-013
 | Need area error <   2.600000000000000E-012  ...
 | PASSED: Area error =   8.171241461241152E-014
 | Need area error <   6.500000000000000E-012  ...
 | PASSED: Area error =   2.238209617644316E-013
 | Need area error <   1.100000000000000E-011  ...
 | PASSED: Area error =   9.237055564881302E-014

I believe this is relative error, not total, but the fields we use in these tests all have an average value of two so the "area" total would be in the neighborhood of twice the surface area of a unit sphere, i.e. 8*pi (~25) so total and relative errors should only be an order of magnitude apart regardless.

[jonbob]

We could have a bad or old version of the code, but I think when we actually ran with different smoothed grids, the runoff totals were different. But that was almost two years ago and may not be accurate now.

[jonbob]

We also had problems with one of the early mosart grids not having a consistent mask -- which may have been the ultimate cause of the conservation issues.

[billsacks]

Thanks, @mnlevy1981 (and @jonbob ) - I'll make an issue to regenerate these maps, but won't treat it as super-high priority given that they are probably conserving right now.