Discussion related to addressing horizontal grid issues within the CCPP

[grantfirl]

Internal grid tiling can lead to a lot of confusing logic in code and a proliferation of argument variables (see, e.g. UFS fractional land mask).

• Some schemes needed to be modified to operate on land, ocean, ice fractions
• Interstitial schemes are needed to split and combine
  Other examples that might need something similar:
• Multiple PBL subcolumns or convective plumes
• Subcolumns related to cloud fraction, precipitation fraction, etc.
• Superparameterization?

Can this be generalized by the framework to clean up the code? (automatic splitting/combining, arbitrary # of subcolumns/tiles)

How do we handle multiple surface schemes, land/ocean/sea-ice, each of which may have their own expectations or requirement for tiling/not-tiling?

What about adopting a “physics grid” to facilitate 3D physics and experimenting with increasing/decreasing horizontal grid size? Would the capability to run different schemes on different grids be useful?

[ligiabernardet]

During the CCPP Visioning Workshop we determined that

• The current (manual) approach used in various schemes is NOT portable
  • Writing schemes as point models (k) as opposed to (i,k) can help with subcolumns, using driver on top to iterate over subcolumns and aggregate
• Load balancing is a topic that the CCPP Framework may be able to help with (find day/night points)
  • randomizing grid indices passed in can help – this is a host model issue