Read topography from file different from IC

[bartgol]

Basically, just add an entry in the input file parameter list for Homme, that tells which file to read phis from.

[ambrad]

Also, I strongly recommend following the current EAM convention. With physigrid, a file looks like this:

dimensions:
  ncol = 21600 ;
  ncol_d = 48602 ;
variables:
  double PHIS(ncol) ;
    PHIS:long_name = "surface geopotential" ;
    PHIS:units = "m2/s2" ;
    PHIS:missing_value = 1.e+36 ;
    PHIS:_FillValue = 1.e+36 ;
  double LANDFRAC(ncol) ;
    LANDFRAC:missing_value = 1.e+36 ;
    LANDFRAC:_FillValue = 1.e+36 ;
    LANDFRAC:long_name = "gridbox land fraction" ;
  double SGH(ncol) ;
    SGH:missing_value = 1.e+36 ;
    SGH:_FillValue = 1.e+36 ;
    SGH:long_name = "standard deviation of 3km cubed-sphere elevation" ;
    SGH:units = "m" ;
  double SGH30(ncol) ;
    SGH30:missing_value = 1.e+36 ;
    SGH30:_FillValue = 1.e+36 ;
    SGH30:long_name = "standard deviation of 30s elevation from 3km cube" ;
    SGH30:units = "m" ;
  double LANDM_COSLAT(ncol) ;
    LANDM_COSLAT:missing_value = 1.e+36 ;
    LANDM_COSLAT:_FillValue = 1.e+36 ;
    LANDM_COSLAT:long_name = "smoothed land fraction" ;
    LANDM_COSLAT:filter = "none" ;
  double lat(ncol) ;
    lat:long_name = "latitude" ;
    lat:units = "degrees_north" ;
  double lon(ncol) ;
    lon:long_name = "longitude" ;
    lon:units = "degrees_east" ;
  double PHIS_d(ncol_d) ;

In a non-physgrid topo file, the _d entries are not present.

[PeterCaldwell]

I'm unclear why we would want PHIS in its own file rather than in the IC.

[whannah1]

@PeterCaldwell this brings up a good point, since the initial conditions are never independent of the topography. There was that problem a few years ago where the aquaplanet compsets were using realistic topography, which might have been avoided if the topography was always part of the ncdata file. I would be in favor of combining them, but it would be a lot of tedious work.

[ambrad]

I think we should get opinions from @mt5555 and others. Here is my opinion:

Generating high-quality topography is nontrivial, and once it is done, one tends to do some analysis on it independent of climate fields, such as measure its power spectrum. Once one is happy witj it. the file then gets used for years. The topo file has high value and its provenance is important.

In contrast, IC files are generated all the time, by any of a different number of methods, and may be used only briefly before another is made. In the course of a simulation campaign, one might generate a large number of them for ensembles, to march the simulation toward steady state, and (in the future) perhaps to switch resolutions. In terms of provenance, most of the fields don't really matter; one tends to obtain climate statistics only after the simulation is substantially past the ICs.

If the two file types are combined, then important, high-quality data will be copied repeatedly to any of a number of IC files (if all goes well). One will end up assuming the topography is the same, but only a comparison of phi_s and variance fields between distantly related IC files will confirm it. It will always be possible to mess it up at some point without realizing it, e.g., applying a smoothing filter to PS, qv, etc, and acidentally to phi_s, then propagating this altered topo data to subsequent IC files.

[mt5555]

Topography generation is a complex procedure, requiring several tools, and consistency between PG2 and GLL versions. I think these tools are still relatively immature and may improve with time. Thus I think we should follow the EAM approach and have have the capability to upgrade the recommended topography, without having to then also regenerate every initial condition file. Also, if we fix a bug or otherwise improve the topography tool chain, how do we get other users to use the new topography when they generate a new IC file? Most users probably interpolate from the output from some previous simulation, and we wont have a way to communicate to them that they need to ncks in a new PHIS field. (edit: and a new SGH, SGH30, and PHIS_pg2 fields)

SCREAM v1 transitioned from our "x16" topography to the rougher "x6t" topography. I'm going to propose EAMv3 also transition. For EAMv3, we just need to update the default "nctopo" in the XML, but we can leave all the old IC files unchanged. Most of them are not fully spun up anyway. If someone needs a spun up IC file, for a forecast like simulation, they will probably wont be using any of the default IC files anyway.

[PeterCaldwell]

Ok, that all makes sense. I like the "we spend a lot of time on topography generation and keeping it separate provides useful provenance" argument.

Let's put topo in its own file... but not until v1 is finalized!

[tcclevenger]

This was done in a series of PRs. https://github.com/E3SM-Project/scream/pull/2073 https://github.com/E3SM-Project/scream/pull/2081 https://github.com/E3SM-Project/scream/pull/2088 https://github.com/E3SM-Project/scream/pull/2090. Closing.