Hi Ned, Thanks so much for the input. Chris P. and I have been discussing this off-list and he's provided a number of ideas (such as CollectMultiGrid, etc.), but we haven't yet resolved the issue.
On Fri, Mar 14, 2003, Ned Piburn wrote: > Daniel, > > I'm puzzled why you don't have boundary nodes on your, > well - er - ah, on your boundary. Hmm. I'm sorry, but I don'm not sure what you mean by this. The slice the you see at http://www.physics.cornell.edu/~freedman/OpenDX/pbc.png shows the mesh that runs up to the boundary at the PBC edge. I think Chris was surprised that I had a gap between the values, but as far as I understand it, I don't have a gap. That gap is the same spacing as the normal regular grid of my data points (position- not connection-dependent), it's just that the connections are not present, as I'm sure you're aware. > I do a fair amount of this sort of thing, in Euler and > Lagrange frames of reference and cylindrical and > Cartesian geometries. For the simple Cartesian case, I > use the SCALE module with a -1 in the scaling vector to > reflect across the appropriate plane. As you point Is this any different than using a translate or a mark-compute-unmark series? Or is it just another method to keep in mind to do a similar thing? > out, this does not produce a new contiguous mesh. It > must be collected with its progenitor and rendered. Okay, but _this_ is the problem area for me. I know how to collect it with it's non-translated ancestor, but I can't get the isosurface to span the gap where the connections are not present. Do you have any ideas how to do so? > There are couple of other gotchas with this technique: > 1) Normals generally to not get recalculated as they > ought to. So what I tend to do is delete the normals > (REMOVE module) and then recalculate them (NORMALS > module). 2) If you have a surface on your plane of > symmetry and then you reflect across that plane, the > outside surface will have a seam in it. Remove that > extra surface on the plane of symmetry and the seam > will go away. Note that ISOSURFACE does not generate > mesh boundary surfaces, you generally have to go to > some extra trouble (SHOWBOUNDARY, BAND, INCLUDE) to > create them. Okay, I don't think I have to worry about this problem, since I don't use normals and don't have surfaces on my plane of symmetry. Anyway, if you see in my vis pic: http://www.physics.cornell.edu/~freedman/OpenDX/pbc.png Essentially, I want to find a way to connect the half-spheres. Any help you or others might provide is very much appreciated. Best wishes, Daniel > -Ned Piburn > > > Daniel Freedman wrote: > > > > Please excuse my resending this. I'm not sure the first email got > > through to the list. Thanks for your help! -Daniel > > > > ------------ > > > > Hi, > > > > I've search the OpenDX reference, quick start, and mailing lists, as > > well as read VIS's "Paths to Visualizations" (which is quite helpful), > > but cannot find any guidance on this matter. > > > > I want to translate (or copy--which is just a tranlate then collect > > original plus translated) a data field, with regular cubic positions > > and connections, by the size of my bounding box to better visualize > > my system which physically has periodic boundary conditions. > > > > I can think of two easy ways to do this: > > > > 1. Mark ("positions"), Compute, Unmark ("positions") > > > > 2. Translate module > > > > The big problem with both of these (which I had hoped the Translate > > module would fix, even if Mark-Compute did not, due to Translate's > > more specific function), is that the connections are broken across the > > border between the old and the new data set (at the periodic boundary > > condition). This is easily seen with the ShowConnections module. > > (For the next few days, I'll leave a demo of this exactly at: > > http://www.physics.cornell.edu/~freedman/OpenDX/pbc.png) > > > > The greater difficulty with this, of course, is that a subsequent > > isosurface across the periodic boundary condition shows a noticeable > > and detracting void, where the missing connections should exist. > > > > I'm actually quite surprised not to have come across additional > > references to this scenario, as (at least from my vantage point) it > > appears quite common and the solution seems non-obvious to me. > > > > I'd appreciate if folks have guidance either on how to properly > > translate to handle the connections across the PBC, or to also > > Mark-Compute on the connections field to similarly translate them > > (it's not clear to me how to operate on the mark'd connections product > > mesh to get it to Do the Right Thing). It seems to me that explicit > > creation of the connections field, via a Regrid module, would be quite > > cumbersome and inelegant. > > > > Thank you kindly for any guidance, > > Daniel > > > > -- > > Daniel A. Freedman <[EMAIL PROTECTED]>, Graduate Fellow > > Electronic Structure Calculations, LASSP, Cornell University -- Daniel A. Freedman <[EMAIL PROTECTED]>, Graduate Fellow Electronic Structure Calculations, LASSP, Cornell University
