Fix routing/runoff for coupled model applications

[sanAkel]

Statement:

Routing table file (e.g., CF0180x6C_TM1440xTM1080-Pfafstetter.TRN) that gets generated by make_bcs script(s) puts run off in wrong locations:

• In the middle of ocean (tile) points (some could be islands?).
• On land (tile) points.

See following figure, locations are marked in panels (c) and (d). Attached is a terrain map of the Indonesian seas (W Pac) region that can be compared to panel (d). These have major consequences for the coupled model: causing it to crash and leaks in the hydrological budget, to name a few. Comments from @atrayano, @rdkoster and @gmao-rreichle will help.

@yvikhlya has been running this utility to fix above problem to some extent.

History:

• @amolod has asked for a fix since many years.
• More recently effort to centralize boundary conditions (files): @biljanaorescanin and generation (source code) by @weiyuan-jiang et al., requires us to take a fresh look at it.

List of steps to generate a routing file that is currently used:

For e.g., /discover/nobackup/projects/gmao/ssd/aogcm/atmosphere_bcs/Icarus-NLv3/MOM6/CF0180x6C_TM1440xTM1080_newtopo/CF0180x6C_TM1440xTM1080-Pfafstetter.TRN

1. Run make_bcs package. This will produce a TRN file, but it directs runoff to the land, that is incorrect (see below figures).

2. Take the TRN file from above step 1 and run @yvikhlya's reroute.py utility (see code at https://github.com/GEOS-ESM/GMAO_Shared/blob/main/GEOS_Util/coupled_diagnostics/g5lib/src/reroute_runoff/reroute.py) which fixes the routing so it ends up being in the ocean.

3. Incorporate @lcandre2 's runoff pathways so that runoff from glaciers is routed to the ocean in a more realistic way. Where is the script/code? ETA: I have this code (though is now several years old). It assigns tiles to a 'topographically appropriate' ocean cell. Because the current routing scheme simply puts runoff in the geographically nearest ocean cell (which is incorrect as frequently as it is correct). The longer term fix - which needs to be started - is to develop catchments and a pfafstetter routing scheme for landice and treat landice as a true child of surface.

4. Possibly (if the coupled model or ocean component blows up at run time) iterate the above 2 and/or 3 if too much freshwater is sent to the ocean. This will be done manually by modifying the ocean mask used in steps 2 and 3, such modified ocean mask, used for routing should be saved somewhere.

Note:

• Step 4 cannot be codified.
• Current make_bcs script(s) does not include above steps 2- 4, they are being done outside (manually) as described ⬆️ .

Action items:

• We need to have steps 2 and 3 included in the make_bcs script(s).

@yvikhlya 's comments on how to get :arrow_up: done:

Actually, the problem is in this utility

https://github.com/GEOS-ESM/GEOSgcm_GridComp/blob/develop/GEOSagcm_GridComp/GEOSphysics_GridComp/GEOSsurface_GridComp/Utils/Raster/mk_runofftbl.F90

What it should do at the very start is to read tile file, read MOM mask and mark all tiles which fall on MOM land as land (change code from 0 to 20). 
Then do what it currently does. This would eliminate re-routing step.

If manual manipulation with routing is necessary, we would feed this utility a fake mask. Done.

cc: @wmputman, @tclune, @atrayano, @weiyuan-jiang

[sanAkel]

FWIW, I tried @yvikhlya's utility myself.

1. It did not reproduce the same output that @yvikhlya has /discover/nobackup/projects/gmao/ssd/aogcm/atmosphere_bcs/Icarus-NLv3/MOM6/CF0180x6C_TM1440xTM1080_newtopo/CF0180x6C_TM1440xTM1080-Pfafstetter.TRN
2. However, it seems to work see below.

[sanAkel]

Tagging https://github.com/GEOS-ESM/GEOSgcm_GridComp/issues/495

[gmao-rreichle]

@sanAkel Thanks for writing this up, very helpful. But I'm not convinced that the following statement is correct:

Routing table file (e.g., CF0180x6C_TM1440xTM1080-Pfafstetter.TRN) that gets generated by make_bcs puts run off in wrong locations:

In the middle of ocean (tile) points (some could be islands?). On land (tile) points.

If by "make_bcs" here you're referring to the existing utility (that is, only Step 1. in the "List of steps to generate a routing file that is currently used" above), then the (lat/lon) locations that receive the runoff make sense from a land perspective. The points "in the middle of the ocean" are islands, and runoff from islands should go into the ocean. One example is Key West (see image below). Runoff can also seemingly be dumped "on land (tile) points" when estuaries stretch inland. One such example is in north-western Borneo (see image below).

I recognize that from the ocean model perspective, it may not work to receive runoff "on land (tile) points" because MOM doesn't operate there, and I thought that this is what Steps 2.-4. are meant to address. I also agree that it would be good to include Steps 2.-4. in make_bcs. But I don't necessarily see anything wrong with make_bcs in its existing scope (i.e., before the connections to the ocean model are made).

Does that make sense? I'm mostly still trying to understand the problem.

[sanAkel]

Thank you @gmao-rreichle.

@sanAkel Thanks for writing this up, very helpful. But I'm not convinced that the following statement is correct:

Routing table file (e.g., CF0180x6C_TM1440xTM1080-Pfafstetter.TRN) that gets generated by make_bcs puts run off in wrong locations:

In the middle of ocean (tile) points (some could be islands?). On land (tile) points.

If by "make_bcs" here you're referring to the existing utility (that is, only Step 1. in the "List of steps to generate a routing file that is currently used" above), then the (lat/lon) locations that receive the runoff make sense from a land perspective.

You are correct. I should have been more precise, for instance refer to mk_rounofftbl.f90? But I didn't because I am not entirely clear of the make_bcs package workflow. Therefore, in the ⬆️ I now refer to make_bcs script(s) as a package.

The points "in the middle of the ocean" are islands, and runoff from islands should go into the ocean. One example is Key West (see image below). Runoff can also seemingly be dumped "on land (tile) points" when estuaries stretch inland. One such example is in north-western Borneo (see image below).

Indeed. When the ocean is coarse (fine) resolution this problem may (may not) be so difficult. But from what I can tell, those islands have not (yet?) caused troubles. But should certainly think ...

I recognize that from the ocean model perspective, it may not work to receive runoff "on land (tile) points" because MOM doesn't operate there, and I thought that this is what Steps 2.-4. are meant to address. I also agree that it would be good to include Steps 2.-4. in make_bcs.

Since you agree to it as well, would you please take a look at @yvikhlya's script: https://github.com/GEOS-ESM/GMAO_Shared/blob/main/GEOS_Util/coupled_diagnostics/g5lib/src/reroute_runoff/reroute.py

I am certain @atrayano will add to this conversation.

But I don't necessarily see anything wrong with make_bcs in its existing scope (i.e., before the connections to the ocean model are made).

Right! My mistake! As said above, I now refer to make_bcs script(s) as a whole.

Does that make sense? I'm mostly still trying to understand the problem.

Very much! 👍 Thanks again!

[yvikhlya]

All, as @sanAkel mentioned above, the problem is in mk_runofftbl.F90, which is called by mk_bcs. It should be aware of MOM land-sea mask and should not put runoff on MOM land. In GEOS set up, MOM land-sea mask is different from GEOS mask and this creates a number of complications in coupled model, including runoff re-routing. If mk_runofftbl.F90 was aware of MOM mask, re-routing step would not be necessary.

@sanAkel Thanks for putting this issue together.

[sanAkel]

Plots with MOM's land-sea mask (black color; value=0.)

[atrayano]

I agree with @yvikhlya - the correct way to "fix" the issue is to make mk_runofftbl.F90 aware of the ocean mask. My only issue is that reading of the ocean mask should be portable, so that it works for MOM (and MOM6), as well as for MITgcm

[yvikhlya]

I agree with @yvikhlya - the correct way to "fix" the issue is to make mk_runofftbl.F90 aware of the ocean mask. My only issue is that reading of the ocean mask should be portable, so that it works for MOM (and MOM6), as well as for MITgcm

Atanas, reading ocean mask IS portable now, since we have this MAPL_Tripolar.nc file regarless which ocean model we use. The mask should be red from this file. Then i,j for ocean tiles should be read from tile file and if mask(i,j)==1, then this tile should be labeled as land.

[atrayano]

The is portable for tripolar grids. MITgcm uses lat-lon-cap (LLC) grid. The good news is that they have the same assumption that mask is strictly 0 or 1. And a minor correction to Yury's comment, the corect type for land is 100, not 20. 20 is the code for land-ice

[yvikhlya]

The is portable for tripolar grids. MITgcm uses lat-lon-cap (LLC) grid. The good news is that they have the same assumption that mask is strictly 0 or 1. And a minor correction to Yury's comment, the corect type for land is 100, not 20. 20 is the code for land-ice

It does not matter if the ocean grid is tripolar or LLC, in any case we'll extract mask from a native ocean grid file and put it to MAPL_Tripolar.nc, perhaps the name will need to be changed to MAPL_OceanGrid.nc or something like this.

[atrayano]

Yes, we can extract the MIT ocean mask and put in a netCDF file. My preference would be to call it with a more general name, even MAPL seems a bit awkward in naming such file. But the bottom line is that we should read the mask from a file and make few changes to the file mk_runofftabl.F90. I'll try to do this by the end of next week

[yvikhlya]

But the bottom line is that we should read the mask from a file and make few changes to the file mk_runofftabl.F90. I'll try to do this by the end of next week

Yes, this sounds like a good solution. This will eliminate all this re-route step with f2py and other ugliness.

[sanAkel]

Yes, we can extract the MIT ocean mask and put in a netCDF file. My preference would be to call it with a more general name, even MAPL seems a bit awkward in naming such file. But the bottom line is that we should read the mask from a file and make few changes to the file mk_runofftabl.F90. I'll try to do this by the end of next week

Thank you @atrayano and @yvikhlya for the ⬆️ discussion. Agreed with (almost all of) it (see ⬇️ for exception).

Looking at MAPL_Tripolar.nc that is:

• /discover/nobackup/projects/gmao/ssd/aogcm/ocean_bcs/MOM6/1440x1080_newtopo/MAPL_Tripolar.nc It has been (can be) generated from this code.

• As the doc: README.md for MAPL_Tripolar says, it uses data that was generated as part of MOM INPUT/ files ( to be specific: /discover/nobackup/projects/gmao/ssd/aogcm/ocean_bcs/MOM6/1440x1080_newtopo/INPUT/) and puts it in the MAPL_Tripolar.nc.

So in essence, it is duplicating information ➡️ copying info from INPUT/ into MAPL_Tripolar.nc This duplication is unnecessary. It's best we to avoid it. I am not saying we change MAPL_Tripolar.nc That would be a separate issue.

But I am not favoring another copy of the mask file:

It does not matter if the ocean grid is tripolar or LLC, in any case we'll extract mask from a native ocean grid file and put it to MAPL_Tripolar.nc, perhaps the name will need to be changed to MAPL_OceanGrid.nc or something like this.

Variable: wet in /discover/nobackup/projects/gmao/ssd/aogcm/ocean_bcs/MOM6/1440x1080_newtopo/INPUT/ocean_topog.nc is the original mask, there is no need to extract and write it to another file.

@atrayano please point me to MITgcm files, I'll find you the equivalent variable (like MOM's wet).

If (ocean model == "MOM6"):
 use `ocean_topog.nc:wet`
else if (ocean model == "MITgcm"):
 use `??:??` ⬅️ @atrayano 
else
 **ERROR**
endif

[yvikhlya]

@sanAkel With MAPL_Tripolar.nc we are avoiding having multiple tripolar grid factories in MAPL, make_bcs, plotting package and any other package which uses an ocean grid. We have 4 different tripolar grid formats and MIT grid is coming. We discussed this many times already. This was suggested by @bena-nasa, since this removed a lot of pain from his shoulders and I like this suggestion.

[sanAkel]

@sanAkel With MAPL_Tripolar.nc we are avoiding having multiple tripolar grid factories in MAPL, make_bcs, plotting package and any other package which uses an ocean grid. We have 4 different tripolar grid formats and MIT grid is coming. We discussed this many times already. This was suggested by @bena-nasa, since this removed a lot of pain from his shoulders and I liked this suggestion.

Understood and already said ⬆️

I am not saying we change MAPL_Tripolar.nc That would be a separate issue.

[lcandre2]

Just for the record on point 3 in original, @lcandre2 has the topographies, drainage basins, and code (though is now several years old). It assigns tiles to a 'topographically appropriate' ocean cell. So, my understanding of the order is 1. land tiles are routed to the appropriate river outlet location on the dataocean grid cell. 2. my scripts modify the routing table generated in 1 for necessary landice tiles. 3. Yury's utility then moves the outlets to the nearest model ocean grid. 4. Manually modify model ocean outlet points to deal with model ocean diffusion issues.

@yvikhlya let me know if I made mistakes.

Because the current routing scheme simply puts runoff in the geographically nearest ocean cell (which is incorrect as frequently as it is correct). The longer term fix - which needs to be started - is to develop catchments and a pfafstetter routing scheme for landice and treat landice as a true child of surface.

[yvikhlya]

My utility will be integrated into mk_runofftbl.F90 Whatever input this program takes should have river runoff and landice in correct locations.

[lcandre2]

@yvikhlya, agreed. I think the goal now is that landice modifications will be incorporated into the river outlet file and then the mk_runofftbl.F90 will incorporate information about different ocean masks. Will there still need to be be manual adjustments to deal with diffusion issues?

[yvikhlya]

@yvikhlya, agreed. I think the goal now is that landice modifications will be incorporated into the river outlet file and then the mk_runofftbl.F90 will incorporate information about different ocean masks. Will there still need to be be manual adjustments to deal with diffusion issues?

We don't this yet, but if manual adjustments will be necessary, this can be easily done by feeding modified ocean mask to mk_runofftbl.F90

[sanAkel]

Will there still need to be be manual adjustments to deal with diffusion issues?

As @yvikhlya said ⬆️ @lcandre2, we do not know-- until we try. But FWIW, we have not yet run into an issue with MOM6 that needed an adjustment. Collectively we have > 40 years of simulations thus far. (Not having run into an issue does not mean, there won't be one in future! 😮 )

[gmao-rreichle]

A quick update: I spoke with @rdkoster and @biljanaorescanin about updating the land information that lists the lat/lon coordinates of the river outlets into the ocean, along with the contributing tile IDs. This effort will update the original 2-by-2.5-degree information that Max put together with input from @rdkoster and that is currently processed by make_bcs into the routing table file (e.g., /discover/nobackup/projects/gmao/ssd/aogcm/atmosphere_bcs/Icarus-NLv3/MOM6/CF0180x6C_TM1440xTM1080_newtopo/CF0180x6C_TM1440xTM1080-Pfafstetter.TRN) (see comments above). Yujin Zeng (@zyj8881357) will tackle this task, but he is not yet on the NASA IT network (ie, does not have access to NCCS/Discover) and he is not yet a member of the GEOS-ESM team. But Yujin should be able to read and comment on this Github issue to facilitate information exchange between the land and ocean groups.
cc: @yvikhlya @sanAkel @lcandre2

[zyj8881357]

I will review all this information.

[sanAkel]

I will review all this information.

Most likely you don't have access to MS Teams? In which case, if needed, I can set up a meeting via google meet. Let me know.

[sanAkel]

A quick update: I spoke with @rdkoster and @biljanaorescanin about updating the land information that lists the lat/lon coordinates of the river outlets into the ocean, along with the contributing tile IDs. This effort will update the original 2-by-2.5-degree information that Max put together with input from @rdkoster and that is currently processed by make_bcs into the routing table file (e.g., /discover/nobackup/projects/gmao/ssd/aogcm/atmosphere_bcs/Icarus-NLv3/MOM6/CF0180x6C_TM1440xTM1080_newtopo/CF0180x6C_TM1440xTM1080-Pfafstetter.TRN) (see comments above).

Yujin Zeng (@zyj8881357) will tackle this task, but he is not yet on the NASA IT network (ie, does not have access to NCCS/Discover) and he is not yet a member of the GEOS-ESM team. But Yujin should be able to read and comment on this Github issue to facilitate information exchange between the land and ocean groups.

cc: @yvikhlya @sanAkel @lcandre2

Thank you @gmao-rreichle. Appreciate it!

[zyj8881357]

I will review all this information.

Most likely you don't have access to MS Teams? In which case, if needed, I can set up a meeting via google meet. Let me know.

I am able to join MS Teams meeting without any problems. Thanks for asking!

[rdkoster]

Looking at my old directories, I see that I am the one who originally created (long ago!) the files lonraster.dat and latraster.dat. Atanas, is it my understanding that if these files are regenerated with the improved routing network information and providing improved ocean outlet information, all of the codes downstream will work? That is, if you get a new version of lonraster.dat and latraster.dat with identical formatting (and thus identical resolution for now) but improved information content, our job on the land side would be done?

[atrayano]

Randy, this seems to be a very reasonable assumption (except perhaps the resolution)

Atanas

[lcandre2]

@rdkoster @atrayano , I agree, but I would like to check/modify the information for landice tiles too.

[gmao-rreichle]

@rdkoster, @atrayano,

Re. lonraster.dat and latraster.dat: I found copies of these files in land01.gsfc.nasa.gov:/land/koster/ where they were sitting among a ton of other, presumably unrelated stuff and without any documentation. Are these files archived somewhere with the bcs input data? I could not find them on Discover. @biljanaorescanin, can you please capture these files in the bcs_shared project disk and make sure they're documented.

I guess the following reader provides some information? GEOSgcm_GridComp/GEOSagcm_GridComp/GEOSphysics_GridComp/GEOSsurface_GridComp/Utils/Raster/read_riveroutlet.F90 If I'm guessing correctly, the files contain 8640-by-4320 longitude and latitude values. These values indicate for each of the 8640-by-4320 grid cells the longitude and latitude of the river outlet into the ocean. (How about endorheic basins?) Maybe someone can visualize the content of the current files.

If that's all correct, then I do not think that reproducing these files will give us what we need. Isn't our current raster grid for tile IDs (based on SRTM data) at much finer resolution than 8640-by-4320? Wouldn't we want the mapping be from land (and landice) tiles to lat/lon of river outlets? Or, perhaps alternatively, from the high-res raster file to lat/lon of river outlets? (I suppose the latter option would not be suitable as a direct input to the model and would, in any case, need to be processed into the former?)

PS: I removed the extraneous email trail from the previous comment. My recommendation would be to enter comments/replies directly on Github.com and not email-reply to system-generated emails, which gunks up the Github pages.

[rdkoster]

The way the old code worked, the coordinates of the final river outlet (to ocean) was identified for each land pixel based on the land mask information we were using. We then "spiraled out" from those outlet coordinates until we found the closest location considered by the ocean model to be "ocean". Accordingly, for the new files, we would need to work with the latest ocean mask. Biljana, can you locate that file and send it to Yujin? We worked with an 8640x4320 array before (again, a long time ago!), with 0 values in the array indicating ocean points.

[rdkoster]

Sorry, I posted my comment before the page refreshed with Rolf's comment. In any case, I understand how the two files were created and what they contain, and I can guide the creation of the new files at whatever resolution is needed.

[gmao-rreichle]

@rdkoster, thanks for the additional info. Maybe I'm misunderstanding all of this, but I thought what we need to produce is a list of lat/lon coordinates with (final) river outlets (to ocean) based solely on the land (and landice) tile space, along with the tile IDs of all the upstream land tiles that contribute to each outlet. This is what's encoded in the SRTM-based Pfafstetter information. Once we have the lat/lons of the river outlets and the upstream tile IDs, the ocean group can take a look at the lat/lons and decide which ocean tile(s) should receive the freshwater associated with our river outlets.
In other words, we (the land group) would not be concerned with the ocean mask. This will make the processing more modular. There are several land tile spaces (resolutions) and many ocean masks of interest, and the first step (of identifying the river outlets and contributing land(ice) tiles according to the Pfafstetter classification should not depend on the ocean mask.

[rdkoster]

I was just describing what went into the previous incarnation of those two files. The file loncenter.dat, which is currently being used, contains an 8640x4320 array of ocean outlet i-indices (for a 2.5'x2,5' grid) for each 2.5'x2.5' location on the Earth; latcenter.dat contains the equivalent array of j-indices. These outlet indices were adjusted as described above to agree with old-ocean-mask ocean locations before they were written out. Anyway, that's the format of the files currently being used to generate the land-to-ocean transfers and, specifically, to key (by some other program, written by Max or Atanas?) the tile-generated runoffs to ocean sinks. Just trying to explain these two datasets...

[sanAkel]

Hi All (@rdkoster, @gmao-rreichle),

• I don't know what was done some 15- or 20- years ago to generate ocean ancillary files (bathymetry, masks, etc), but knowing what we have with MOM5 and now MOM6 based models, much of it was taken from elsewhere-- the key point is that: there is no traceability and certainly no "self-control" for content(s) of any dataset. This is all rapidly changing! All I am trying to say is that, it would be easier to ask:
  • What do we want to do?
  • What utilities/information (SRTM) do we have?
  • How well does this solve our problem?
  • There on, CI takes over!

(In that spirit, I can assure that none of us can track down the source of data in SEAWIFS_KPAR_mon_clim.180x1080, in /discover/nobackup/projects/gmao/share/gmao_ops/fvInput/g5gcm/bcs/realtime/OSTIA_REYNOLDS/180x1080/ 😱 )

Having said ⬆️ I am very much supportive of improving the lonraster.dat and latraster.dat but I see that as another step. For now I would ❤️ to see the Action items listed at https://github.com/GEOS-ESM/GEOSgcm_GridComp/issues/681#issue-1474217474 resolved. Thank you!

[sanAkel]

⬆️ Suggested fix:

For mk_runofftbl.F90 happening via https://github.com/GEOS-ESM/GEOSgcm_GridComp/tree/feature/sanAkel/partial-fix-issue-681

[yvikhlya]

⬆️ Suggested fix:

For mk_runofftbl.F90 happening via https://github.com/GEOS-ESM/GEOSgcm_GridComp/tree/feature/sanAkel/partial-fix-issue-681

This reroute subroutine is not actually needed. After ocean mask is read, all tile types where mask(i2, j2)=0, where i2, j2 - indexes of second grid in the tile file, should be changed from 0 to 100. This is it.

[sanAkel]

Thank you @yvikhlya I was trying to have following discussion with @atrayano:

I wanted to get this issue out of our way. So started this branch: https://github.com/GEOS-ESM/GEOSgcm_GridComp/tree/feature/sanAkel/partial-fix-issue-681 . But as I got closer to finishing it realized that we were wrong:

Thought was that mk_runofftbl.f90 needs to be "aware" of ocean and its mask. That's what I tried to do ... as @atrayano and @yvikhlya said ⬆️

For that to happen, whatever tiles are inconsistent between .til file (type is = 0: ocean) should be "cross-checked" with ocean-mask and if the mask says no, they are not ocean, then correct them to be land tile-type, i.e., 100. ⬅️ that's what @atrayano concurred with @yvikhlya

I agree with @yvikhlya - the correct way to "fix" the issue is to make mk_runofftbl.F90 aware of the ocean mask. https://github.com/GEOS-ESM/GEOSgcm_GridComp/issues/681#issuecomment-1344657012

But here is the real question:

• Why did the .til file even make that mistake: i.e., mark those points ocean??
• Why is mk_runtbl.f90 being handed off a WRONG tile file-- for coupled model purpose. That's the central problem here- as I see it now.

Given this, I am not supportive of patching a downstream app such as mk_runtbl.f90

FWIW, if a patch is the only way out, we can just "package" @yvikhlya's script

But a PROPER fix is what we should work towards. That will really CUT down if not, eliminate other bad issues such as "orphan" points, sink holes in our budgets and whatnot in our COUPLED model.

It is my understanding that @GEOS-ESM/land-team are not insistent on anything that ends up used for coupled applications: with the ocean. If any, they do want to clean up as well.

[yvikhlya]

I support approach suggested by @sanAkel, i.e. moving a fix for river routing from routing table level to tile file level, in other words, making a coupled tile file mask to be identical to ocean model mask. This would solve multiple issues in coupled model at once. If there are any obstacles in implementing this approach, I would like to know what are these obstacles exactly.

[atrayano]

@yvikhlya and @sanAkel Making a .til for the coupled model based on the ocean mask is not a very good idea: this effectively will "modify" the land tile definitions and we will have totally incompatible boundary conditions and restarts between coupled and AMIP runs. I firmly believe that the best compromise for us is to mk_runofftabl.F90 aware of the actual ocean mask and always send the runoff fresh water to an actual ocean point

[sanAkel]

@atrayano

we will have totally incompatible boundary conditions and restarts between coupled and AMIP runs.

It is my understanding from @biljanaorescanin that we already have different boundary conditions between coupled and AMIP. Moreover, it makes sense that they are different! Every run of make_bcs generates a totally self-contained set of files, so there is no mix-and-match of boundary conditions generated for coupled getting used in AMIP or other way around.

As for:

restarts between coupled and AMIP runs.

This is also an existing pre-condition, i.e., it already exists! I routinely remap restarts from AMIP to coupled. I could never simply plug in - model crashes!

Is it possible to generate such a tile file and SEE how it looks?

[yvikhlya]

Making a .til for the coupled model based on the ocean mask is not a very good idea: this effectively will "modify" the land tile definitions and we will have totally incompatible boundary conditions and restarts between coupled and AMIP runs.

We already have different set of BCs and restarts for AMIP and coupled models. The question is, if we convert some ocean tiles into land tiles, to make GEOS land-sea mask to be identical to MOM land-sea mask, will it be possible to generate BCs and ICs for these tiles? I guess, this is a question for @gmao-rreichle and @biljanaorescanin

[gmao-rreichle]

A couple of thoughts on this:

1. Ideally, the (land/landice/lake/ocean) tile spaces and BCs would be the same for the AGCM and the coupled model. This isn't the case now. I'm wondering if there's any way this could be accomplished. Perhaps we'd need a new type of "estuary" tile that is used to connect the land and the ocean. Or maybe "lake" tiles could even be used (rather than introducing a new type), given that "lakes" are just infinite water reservoirs with a surface energy budget (presumably what "estuaries" would be initially). If this can work, then we should be able to interchange BCs and ICs seamlessly between the AGCM (ie, FP & AMIP) and the coupled model.

2. Currently, the land tiles and files of the coupled model BCs can be used in the GEOSldas land-only (offline) system, so we can create reasonably spun-up ICs offline. This isn't optimal, though. Even worse is the "regrid.pl" / "remap_restarts.py" approach of simply interpolating from one (land) tile space to another (which seems to be what @sanAkel is doing to get by).

3. Having said that, if we are indeed making land out of ocean (where ocean is defined by the 10 arcsec mask file GEOS5_10arcsec_mask.nc), then how are soil, topography, vegetation parameters assigned? I assume this is happening somehow in the current make_bcs post-processing. Are the parameter values from nearby land tiles duplicated? Or are the "new" land tiles merged into nearby existing land tiles?

I can't say I understand what the ocean model considers ocean and how that relates to the reference, 10 arcsec mask file (GEOS5_10arcsec_mask.nc), and I'm probably missing a bunch of things. But the more I think about what is done to make the coupled model work, the less sense it makes to me.

cc: @rdkoster @yvikhlya @lcandre2 @biljanaorescanin

[sanAkel]

@gmao-rreichle Those are great comments.

I'm finding increasingly convinced that we need to take a fresh/clean look at all this...

As time permits, in next few days I will upload plots of GEOS 10 arc second dataset and GEBCO 15 arc Sec that we use for ocean- that's probably the "other end point"! That may help firm your ideas (number 1: estuary).

[sanAkel]

Making a .til for the coupled model based on the ocean mask is not a very good idea: this effectively will "modify" the land tile definitions and we will have totally incompatible boundary conditions and restarts between coupled and AMIP runs.

We already have different set of BCs and restarts for AMIP and coupled models. The question is, if we convert some ocean tiles into land tiles, to make GEOS land-sea mask to be identical to MOM land-sea mask, will it be possible to generate BCs and ICs for these tiles? I guess, this is a question for @gmao-rreichle and @biljanaorescanin

Based on @gmao-rreichle's comments, it seems possible. Did I get that right?

And yes, I use regrid.pl or it's python version: remap_restarts.py to convert from one kind of tiles (amip) to another (coupled): I do account for spin up in all my "science" results.

[yvikhlya]

I can't say I understand what the ocean model considers ocean

Ocean model has its own land-sea mask which is not very realistic in some regions. This creates a number of complications in coupling ocean with atmophere/land models.

[sanAkel]

I can't say I understand what the ocean model considers ocean

Ocean model has its own land-sea mask which is not very realistic in some regions. This creates a number of complications in coupling ocean with atmophere/land models.

I would say coastline is rather "boxed up" or choppy, not as realistic as "nature". Well, that gets "better" at higher resolutions. But all that is besides the main point of tile file reconciliation.

[yvikhlya]

The idea of introducing a new tile type looks interesting.

[sanAkel]

Here is a comparison of the masks based on MOM5 based S2S-v3 output at: /archive/u/gmaofcst/GEOS5.0/M2OCEAN_S2SV3/

• Left panel: MOM5 land-sea mask
• Right panel: FROCEAN from GEOS
• The ocean model is at a nominal 1/4-deg resolution.

[sanAkel]

With no action, this issue has gone stale! The root cause of the problem continues to persist, without any resolution. There is no point in having open issues with no solution.

[gmao-rreichle]

@sanAkel: "Stale" isn't quite right. Yujin has delivered the new, higher-res outlet files to Atanas who was going to use them to create updated TRN files. Alas, the latter hasn't happened yet. We just asked Yujin to look into this step. It may be too big of an ask, given that Yujin has virtually no experience with GEOS. But he's working on the land routing and needs to understand the TRN file anyway. With any luck and - hopefully - some support from Atanas, this is still moving ahead.