[mpas-developers] proposed additions to global_scvt

[Doug Jacobsen]

Hi Michael,

I think that's fine. The header line is easy enough to remove if you need
it. The more difficult part was dealing with the format of the points.

Thanks!
Doug

On Thu, Jan 5, 2012 at 11:00 AM, Michael Duda <duda at ucar.edu> wrote:

> 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
> > > >
> _______________________________________________
> mpas-developers mailing list
> mpas-developers at mailman.ucar.edu
> http://mailman.ucar.edu/mailman/listinfo/mpas-developers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ucar.edu/pipermail/mpas-developers/attachments/20120105/e5236c23/attachment.html