Roy Stogner <[email protected]> wrote on 10/27/2010 02:50:30 PM:
>
> On Wed, 27 Oct 2010, David Andrs wrote:
>
> > Roy Stogner <[email protected]> wrote on 10/27/2010 01:19:07
PM:
> >
> > > What kind of translations are they doing?
> >
> > Currently they do two types:
> >
> > 1) A wedge-shaped domain (see per1.png) (origin is at the bottom
> > corner). The translation depends on x-coordinate (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 vector-valued, assuming the user can
> specify covariance vs contravariance) results right even with your
> very-general 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 as-is; 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.
I fixed the memory leak and checked the patch in. I also renamed the
method for computing points on the other side to get_corresponding_pos, so
that the name does not imply only translation.
If someone is going to implement the rotation vector (mentioned above),
I'd like to mention that we need to run our user code inside
get_corresponding_pos, so we rely on this API.
--
David
> ---
> Roy
>
>
------------------------------------------------------------------------------
> Nokia and AT&T present the 2010 Calling All Innovators-North America
contest
> Create new apps & games for the Nokia N8 for consumers in U.S. and
Canada
> $10 million total in prizes - $4M cash, 500 devices, nearly $6M in
marketing
> Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
> http://p.sf.net/sfu/nokia-dev2dev
> _______________________________________________
> Libmesh-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/libmesh-devel
------------------------------------------------------------------------------
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
http://p.sf.net/sfu/nokia-dev2dev
_______________________________________________
Libmesh-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
