Hi Michael,<br><br>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.<br><br>Thanks!<br>Doug<br><br><div class="gmail_quote">
On Thu, Jan 5, 2012 at 11:00 AM, Michael Duda <span dir="ltr"><<a href="mailto:duda@ucar.edu">duda@ucar.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi, Folks.<br>
<br>
I'd like to go ahead and make the changes in global_scvt to write out<br>
refinement points automatically in the locs.dat.out file, and to compute<br>
estimates for the required number of generating points.<br>
<br>
On the topic of file format, I think we could easily adopt the format<br>
mentioned below, but I think it would be best for now to keep the header<br>
line: since we might not always be reading the points into a dynamic<br>
data structure, having a header line lets us avoid reading through the<br>
file once to count the number of lines and again to read in the points;<br>
alternatively, programs reading the file won't need to access, e.g., a<br>
namelist to figure out how many points are in the file. It seems a lot<br>
easier to simply discard the header in programs that don't need it than<br>
to retrofit other programs to either read a namelist or make two passes<br>
through the file.<br>
<br>
So, I'd like to commit the originally proposed changes, and then to<br>
modify the file format to<br>
<div class="im"><br>
x1 y1 z1<br>
x2 y2 z2<br>
...<br>
<br>
</div>keeping the header line, in a separate commit. Does this sound<br>
reasonable to everyone?<br>
<br>
Thanks!<br>
<span class="HOEnZb"><font color="#888888">Michael<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
On Thu, Dec 22, 2011 at 11:31:47AM -0700, Michael Duda wrote:<br>
> Hi, Doug.<br>
><br>
> Improving compatibility between our grid generation codes sounds like<br>
> a good idea. Changing the format to just<br>
><br>
> x1 y1 z1<br>
> x2 y2 z2<br>
> ...<br>
><br>
> would be straightforward, though removing the header would appear to<br>
> cause problems for the grid_ref program. With refinement points now<br>
> being written to the locs.dat.out file, we may be able to dispense with<br>
> the grid_ref program, though this would depend on whether anyone else<br>
> relies on this program.<br>
><br>
> Could anyone who is currently making use of grid_ref in a way that<br>
> couldn't be substituted with the new refined locs.dat.out files comment<br>
> on whether we might be able to eliminate this code? If not, would it<br>
> work to have grid_ref read the namelist.input file to see how many lines<br>
> it should read from the locs.dat.out file?<br>
><br>
> Thanks!<br>
> Michael<br>
><br>
><br>
> On Wed, Dec 21, 2011 at 06:47:38PM -0700, Doug Jacobsen wrote:<br>
> > Hey Michael,<br>
> ><br>
> > While you are making changes anyway.... would there be any way to change<br>
> > the format of the intput/output points? Mainly because it's difficult to<br>
> > take points from my format and make global_scvt read them in.<br>
> ><br>
> > Also, it seemed like the header information in the file was fairly useless<br>
> > in that global_scvt doesn't read it. The way I write my points out (as you<br>
> > have seen before) is a left justified set of cartesian coordinates with a<br>
> > space between them. Like this<br>
> ><br>
> > x1 y1 z1<br>
> > x2 y2 z2<br>
> > ...<br>
> > etc<br>
> ><br>
> > I just figured this would make it more general for other scvt generators,<br>
> > and allow points to be more easily migrated between scvt generators.<br>
> ><br>
> > I don't know if this is something you are interested in changing, but it<br>
> > shouldn't be too difficult.<br>
> ><br>
> > Doug<br>
> ><br>
> > On Wed, Dec 21, 2011 at 5:43 PM, Michael Duda <<a href="mailto:duda@ucar.edu">duda@ucar.edu</a>> wrote:<br>
> ><br>
> > > Hi, All.<br>
> > ><br>
> > > I'd like to propose two small improvements to the global_scvt code.<br>
> > ><br>
> > > The first change is to always write out the final generating points<br>
> > > (i.e., what is currently written) plus a set of refinement points to the<br>
> > > locs.dat.out files. Since the grid_gen program will only read as many<br>
> > > points from the locs.dat file as are specified by the np variable in the<br>
> > > namelist, this change should not disrupt current workflows, but should<br>
> > > enable us to avoid a separate program for refining a grid: when iterations<br>
> > > converge with the current number of generating points, we can copy<br>
> > > locs.dat.out to locs.dat as usual, and simply set np to 4*np-6 in<br>
> > > the namelist.input file.<br>
> > ><br>
> > > The second change adds code to estimate the number of generating points<br>
> > > required to reach a target fine-grid resolution based on the density<br>
> > > function encoded in src/module_scvt.F. The only change from the user's<br>
> > > perspective is the addition of a new variable, min_dx, in the namelist<br>
> > > that specifies the desired minimum resolution; the code will<br>
> > > automatically compute an estimate for the cell count using the following<br>
> > > method:<br>
> > ><br>
> > > area_per_sample = 4.0 * pi * 6370000**2.0 / n_samples<br>
> > > nhexs = 0.0<br>
> > > do i=1,n_samples<br>
> > > call random_point(p)<br>
> > > d = density_for_point(p)<br>
> > > dl = min_dx / (d ** 0.25)<br>
> > > hex_area = sqrt(3.0) / 2.0 * dl**2.0<br>
> > > nhexs = nhexs + area_per_sample / hex_area<br>
> > > end do<br>
> > > write(0,*) 'Estimated # hexs:', nint(nhexs)<br>
> > ><br>
> > > The routine random_point returns uniformly-distributed points on the<br>
> > > sphere. Although the method assumes planar hexagons (rather than<br>
> > > spherical hexagons), the discrepancy becomes smaller as the number of<br>
> > > hexagons increases.<br>
> > ><br>
> > > I've placed a checked-out version of the code (on which you can run<br>
> > > 'svn status' and 'svn diff') at<br>
> > > <a href="http://www.mmm.ucar.edu/people/duda/files/global_scvt_co.tar.gz" target="_blank">http://www.mmm.ucar.edu/people/duda/files/global_scvt_co.tar.gz</a>.<br>
> > ><br>
> > > Any comments or suggestions would be appreciated; if there are no<br>
> > > objections, I'd like to commit the changes to the repository trunk.<br>
> > ><br>
> > > Thanks,<br>
> > > Michael<br>
> > > _______________________________________________<br>
> > > mpas-developers mailing list<br>
> > > <a href="mailto:mpas-developers@mailman.ucar.edu">mpas-developers@mailman.ucar.edu</a><br>
> > > <a href="http://mailman.ucar.edu/mailman/listinfo/mpas-developers" target="_blank">http://mailman.ucar.edu/mailman/listinfo/mpas-developers</a><br>
> > ><br>
_______________________________________________<br>
mpas-developers mailing list<br>
<a href="mailto:mpas-developers@mailman.ucar.edu">mpas-developers@mailman.ucar.edu</a><br>
<a href="http://mailman.ucar.edu/mailman/listinfo/mpas-developers" target="_blank">http://mailman.ucar.edu/mailman/listinfo/mpas-developers</a><br>
</div></div></blockquote></div><br>