Bah. Sometimes you cannot see the proper design until you just start
implementing something.
With that in mind I went forward with my original idea and wrapped up
InverseDistanceInterpolation in a SolutionTransfer interface
(MeshfreeSolutionTransfer)... it make some assumptions, but it works ok.
We can continue to think about what the right thing to do is...
Ben, would you take a look at what I did? In particular, I copied your
Function object from your Meshfree example... should we make that a real
object that multiple people might use... or is it ok to treat it as a local
helper object like I did?
Derek
On Mon, Jan 28, 2013 at 10:53 AM, Derek Gaston <fried...@gmail.com> wrote:
> There are lots of paths and different designs that are possible here.
> I can't see the correct one right now... but I don't think my super
> simple SolutionTransfer interface is the right one for libMesh. I
> think that Ben has something closer to the right interface for libMesh
> in MeshfreeInterpolation. If I try to make
> MeshfreeSolutionTransfer... I can do it, but it will only have a
> limited subset of the MeshfreeInterpolation functionality and will
> have some assumed/deduced quantities (like for number of interpolation
> points and "power") which is not very libMesh like. It would provide
> some simple functionality, but wouldn't be the best fit for a general
> library like libMesh.
>
> I'm going to take a swipe at implementing a DTKMeshfreeInterpolation
> instead and see how that goes...
>
> Derek
>
> Sent from my iPad
>
> On Jan 28, 2013, at 10:11 AM, Roy Stogner <royst...@ices.utexas.edu>
> wrote:
>
> >
> > On Sun, 27 Jan 2013, Derek Gaston wrote:
> >
> >> I set about filling out the SolutionTransfer system tonight... and I
> realized that the code I was writing was pretty high level... and not very
> libMesh
> >> like. �I was hiding quite a lot and assuming quite a lot... and
> providing interfaces that might not be optimal in certain circumstances.
> >> So, here's what I'm thinking... I'm going to do away with the
> SolutionTransfer system in libMesh... and undo the work I was doing. �I'll
> move the DTK
> >> functionality to "misc" and redo the example I added to not use the
> (now deleted) DTKSolutionFunction... but just use the DTK interface classes
> I made
> >> instead.
> >> I think that the MeshfreeInterpolation stuff that Ben has in there
> along with the DTK interfaces provide good library functionality. �People
> can wrap those
> >> up the way that want, if they want.
> >> What do you guys think?
> >
> > I loved the idea of having a higher-level abstract API that could be
> > instantiated with either Ben's stuff or yours. It wouldn't even have
> > to be a *big* API - see MeshInput/MeshOutput/SolutionHistory for a few
> > examples where the abstract base class just can't say much about
> > implementations and so can't be very complicated.
> >
> > But if there's no good way to factor those together then there's no
> > good way; I'd trust your judgement on that.
> > ---
> > Roy
>
------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnnow-d2d
_______________________________________________
Libmesh-devel mailing list
Libmesh-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
