[mpas-developers] proposed additions to global_scvt

[Michael Duda]

Hi, Folks.

I'd like to go ahead and make the changes in global_scvt to write out
refinement points automatically in the locs.dat.out file, and to compute
estimates for the required number of generating points.

On the topic of file format, I think we could easily adopt the format
mentioned below, but I think it would be best for now to keep the header
line: since we might not always be reading the points into a dynamic
data structure, having a header line lets us avoid reading through the
file once to count the number of lines and again to read in the points;
alternatively, programs reading the file won't need to access, e.g., a
namelist to figure out how many points are in the file. It seems a lot
easier to simply discard the header in programs that don't need it than
to retrofit other programs to either read a namelist or make two passes
through the file.

So, I'd like to commit the originally proposed changes, and then to
modify the file format to 

 x1 y1 z1
 x2 y2 z2
 ...

keeping the header line, in a separate commit. Does this sound
reasonable to everyone?

Thanks!
Michael


On Thu, Dec 22, 2011 at 11:31:47AM -0700, Michael Duda wrote:
> 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
> > >