[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