[mpas-developers] proposed standard quasi-uniform grids

Todd Ringler ringler at lanl.gov
Fri Nov 12 14:49:59 MST 2010


Hi Michael,

Thanks for taking a look at these.

Regarding #1:  the NCO utilities add a "history" attribute whenever a utility modifies a file. It seems like a good way to tag a file and trace its lineage, but it is a bit messy.

Regarding #2: yes, I think that these fields should be eliminated from the global_scvt generation code since I can not think of a reason why to keep them. They are there because it was convenient early on. Any thoughts on this from others?

I would be happy to cut these fields from the standard meshes before distribution (probably via ncks), but I am hesitant to regenerate the grids again from scratch in order to not write out a few fields. My approach will mean that the "history" portion of the file will include the action of removing fields. Maybe I can find a way to suppress this.

Cheers,
Todd


On Nov 12, 2010, at 2:40 PM, Michael Duda wrote:

> Hi, Todd.
> 
> I think it would be a great idea to place standard meshes
> on our sourceforge site. I have just a couple of questions
> regarding the contents of the mesh files themselves:
> 
> 1) What is the meaning of the 'history' attribute in the
>   netCDF mesh files? Would this be used to store grid 
>   provenance data, or was this attribute automatically 
>   added by the 'ncatted' utility?
> 
> 2) Recognizing that the grid generation code itself 
>   adds the fields u, v, h, vh, circulation, vorticity, ke,
>   and tracers, should we first modify the global_scvt code 
>   to eliminate these fields before creating the final set 
>   of files to be distributed?
> 
> Otherwise, I think the contents of the tar files looks
> complete.
> 
> Cheers,
> Michael
> 
> 
> On Mon, Nov 08, 2010 at 02:52:32PM -0700, Todd Ringler wrote:
>> 
>> Hi All,
>> 
>> I am proposing that we produce "standard" quasi-uniform global SCVT grids for general use and distribution. Lately we have run across a couple of examples where confusion arose due to using different meshes with same number of grid cells.
>> 
>> Here are the links to the meshes that we have produced:
>> 
>> 480 km: 2562: https://files.me.com/todd.ringler/002lh9
>> 240 km: 10242: https://files.me.com/todd.ringler/t9tker
>> 120 km: 40962: https://files.me.com/todd.ringler/qqy336
>> 60 km: 163842: https://files.me.com/todd.ringler/ghlhxu
>> 30 km: 655362: https://files.me.com/todd.ringler/r4hkk4
>> 
>> Each of these meshes were produced from the trunk/grid_gen/global_scvt directory, rev 572 by Doug Jacobsen at FSU. Each mesh was iterated to a level of converge of 1.0e-11 (this represents the average grid point movement on the unit sphere on each iteration).
>> 
>> Each of the x1.grid.*.nc files have been given global attributes related to when they were generated, from what revision # and that they are considered the "standard" mesh for that resolution.
>> 
>> Each *.tar.gz files contains the locs.dat file, graph.info file and a wide assortment of graph.info.part.* files.
>> 
>> I am requesting feedback on these meshes and the files that are included in the *.tar.gz package. My proposal is to push these out to the sourceforge site once the vetting process is complete.
>> 
>> Cheers,
>> Todd
>> _______________________________________________
>> mpas-developers mailing list
>> mpas-developers at mailman.ucar.edu
>> http://mailman.ucar.edu/mailman/listinfo/mpas-developers
> 



More information about the mpas-developers mailing list