From: Roy Stogner <roystgnr@ic...>  20101027 20:50:37

On Wed, 27 Oct 2010, David Andrs wrote: > Roy Stogner <roystgnr@...> wrote on 10/27/2010 01:19:07 PM: > > > What kind of translations are they doing? > > Currently they do two types: > > 1) A wedgeshaped domain (see per1.png) (origin is at the bottom > corner). The translation depends on xcoordinate (of the source > point) and is reversible by multiplying the translation vector by > 1. > > 2) A skewed square domain (see per2.png). They should be able to do > it the same way as case 1), but they do not want to do it, since > they already have the domain meshed and they want to use it. In this > case, the origin is in the left bottom corner and the periodicity is > from the left to the bottom edge. In this case, the translation from > primary boundary to secondary is different than the other way > around. It sounds like these are both rotations, then? 30 degrees or so for your wedge, 120 for your trapezoid? So instead of "translate by vector T", it would be sufficient to "translate by vector T, then rotate by vector R around the origin" (or the other way around). Either way the default R=0 case would work for existing code, and R=(0,0,pi/6) and R=(0,0,2pi/3) would cover your two cases. > I do not know very much about periodic boundaries, so I only > enhanced (probably the easiest) case of transaltions. If the > rotation needs something more, how would it fit into the > PeriodicBoundary class? Basically we'd just store a rotation vector as well as a translation vector. Then (at least for these cases) subclassing wouldn't be necessary. > And how much different would be the > computation of the angular translation in other parts of code (like > dof_map_constraints.C aorund line 1353, fe_base.C around line 2033) > if it is not possible to capture that by the proposed patch? Actually, after thinking about it some more I realized that it *is* possible to get the C1 (and the vectorvalued, assuming the user can specify covariance vs contravariance) results right even with your verygeneral API  we'd just need to get the face_normals on both sides of the periodic boundary and determine the rotation from them. I'd still prefer a patch that did the translation/rotation vector calculations (as that would be easier to enable from new apps) and I'd be willing to help you if you wanted to write that, but your patch is fine asis; unless anyone else objects, if you want to put that version in the library just let me know when you've got a version with the memory leak fixed.  Roy 