Daniel,
I'm puzzled why you don't have boundary nodes on your,
well - er - ah, on your boundary.
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
out, this does not produce a new contiguous mesh. It
must be collected with its progenitor and rendered.
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.
-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
