[mpas-developers] proposed additions to global_scvt

[Michael Duda]

Hi, Doug.

Improving compatibility between our grid generation codes sounds like 
a good idea. Changing the format to just 

x1 y1 z1
x2 y2 z2
...

would be straightforward, though removing the header would appear to
cause problems for the grid_ref program. With refinement points now
being written to the locs.dat.out file, we may be able to dispense with
the grid_ref program, though this would depend on whether anyone else
relies on this program.

Could anyone who is currently making use of grid_ref in a way that
couldn't be substituted with the new refined locs.dat.out files comment
on whether we might be able to eliminate this code? If not, would it
work to have grid_ref read the namelist.input file to see how many lines
it should read from the locs.dat.out file?

Thanks!
Michael


On Wed, Dec 21, 2011 at 06:47:38PM -0700, Doug Jacobsen wrote:
> Hey Michael,
> 
> While you are making changes anyway.... would there be any way to change
> the format of the intput/output points? Mainly because it's difficult to
> take points from my format and make global_scvt read them in.
> 
> Also, it seemed like the header information in the file was fairly useless
> in that global_scvt doesn't read it. The way I write my points out (as you
> have seen before) is a left justified set of cartesian coordinates with a
> space between them. Like this
> 
> x1 y1 z1
> x2 y2 z2
> ...
> etc
> 
> I just figured this would make it more general for other scvt generators,
> and allow points to be more easily migrated between scvt generators.
> 
> I don't know if this is something you are interested in changing, but it
> shouldn't be too difficult.
> 
> Doug
> 
> On Wed, Dec 21, 2011 at 5:43 PM, Michael Duda <duda at ucar.edu> wrote:
> 
> > Hi, All.
> >
> > I'd like to propose two small improvements to the global_scvt code.
> >
> > The first change is to always write out the final generating points
> > (i.e., what is currently written) plus a set of refinement points to the
> > locs.dat.out files. Since the grid_gen program will only read as many
> > points from the locs.dat file as are specified by the np variable in the
> > namelist, this change should not disrupt current workflows, but should
> > enable us to avoid a separate program for refining a grid: when iterations
> > converge with the current number of generating points, we can copy
> > locs.dat.out to locs.dat as usual, and simply set np to 4*np-6 in
> > the namelist.input file.
> >
> > The second change adds code to estimate the number of generating points
> > required to reach a target fine-grid resolution based on the density
> > function encoded in src/module_scvt.F. The only change from the user's
> > perspective is the addition of a new variable, min_dx, in the namelist
> > that specifies the desired minimum resolution; the code will
> > automatically compute an estimate for the cell count using the following
> > method:
> >
> >   area_per_sample = 4.0 * pi * 6370000**2.0 / n_samples
> >   nhexs = 0.0
> >   do i=1,n_samples
> >      call random_point(p)
> >      d = density_for_point(p)
> >      dl = min_dx / (d ** 0.25)
> >      hex_area = sqrt(3.0) / 2.0 * dl**2.0
> >      nhexs = nhexs + area_per_sample / hex_area
> >   end do
> >   write(0,*) 'Estimated # hexs:', nint(nhexs)
> >
> > The routine random_point returns uniformly-distributed points on the
> > sphere. Although the method assumes planar hexagons (rather than
> > spherical hexagons), the discrepancy becomes smaller as the number of
> > hexagons increases.
> >
> > I've placed a checked-out version of the code (on which you can run
> > 'svn status' and 'svn diff') at
> > http://www.mmm.ucar.edu/people/duda/files/global_scvt_co.tar.gz.
> >
> > Any comments or suggestions would be appreciated; if there are no
> > objections, I'd like to commit the changes to the repository trunk.
> >
> > Thanks,
> > Michael
> > _______________________________________________
> > mpas-developers mailing list
> > mpas-developers at mailman.ucar.edu
> > http://mailman.ucar.edu/mailman/listinfo/mpas-developers
> >