Discussing refactoring; this probably ought to be on one of the public lists.
Something to add to the below discussion: if we're refactoring PeriodicBoundary anyway, and *especially* if we're putting more classes of periodic boundary into the main library, it would be nice to add an abstract base class method that returns a transformation matrix describing "what happens to vectors at the boundary", so we could properly implement C1 and vector-valued element periodic boundaries for the more complicated cases too. Just a half-formed idea. I'm not even sure yet whether we'd need separate matrices for covariant vs contravariant vectors, or whether there's even more magic necessary for H(div) or H(curl) or tensor spaces... --- Roy ---------- Forwarded message ---------- Date: Mon, 20 Aug 2012 12:55:33 -0500 (CDT) From: Roy Stogner <royst...@ices.utexas.edu> To: John Peterson <jwpeter...@gmail.com> Subject: Re: More PeriodicBoundary stuff On Mon, 20 Aug 2012, John Peterson wrote: > PeriodicBoundary *boundary = new PeriodicBoundary(periodic_boundary); > > I've tested this, and the subclass's copy constructor is indeed never > called. Indeed - there's no way to stuff a subclass's data into the superclass, which is all that's constructed in the above line. So there's pretty much no current way to add subclasses except by adding them in properly matched pairs. > 1.) DofMap::add_periodic_boundary(x) instead takes a pointer (which > the user is responsible for new'ing) makes no copy, the pointer gets > deleted by the PeriodicBoundaries class. > DofMap::add_periodic_boundary(x,y) remains unchanged. No - Too easy to end up relying on user-free'd memory. > 2.) We add a virtual clone() method to PeriodicBoundary. Both > versions of DofMap::add_periodic_boundary() take constant references > and clone() them internally before adding them to the > _periodic_boundaries container. This is what we're doing in most similar situations; I'd prefer it for consistency. > 3.) Make all the add_periodic_boundary() interfaces take > AutoPtr<PeriodicBoundary>&, user is responsible for creating those and > knowing that ownership is transferred when calling this function. This is okay. > #2 requires more library changes. If we did this, we might as well go > the full 9 yards and make PeriodicBoundary an abstract base with a > virtual clone(), forcing derived classes to implement it. The > PeriodicBoundary implementing translation (what's currently in the > library) would be a derived class of PeriodicBoundaryBase. Yeah, we'd definitely want to call the ABC PeriodicBoundaryBase so we could still instantiate PeriodicBoundary for backwards compatibility. --- Roy ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
