Hello, On Wed, May 28, 2014 at 08:02:33AM -0500, Roy Stogner wrote: > > Copying to libmesh-devel in case anyone else wants to interject. > > On Wed, 28 May 2014, Robert Weidlich wrote: > > > My aim is to solve standard solid mechanic tasks with contact, so I > > usually need a material and some kind of boundary conditions. In my > > current implementation I have one subclass of FEMSystem and own class > > hierachies for materials (NeoHooke, Ogden, etc) and boundary conditions > > (displacement, traction, standard contact, mortar contact, etc). > > Material and boundary conditions are instanciated and called in my > > FEMSystem subclass. > > > > I saw that you factored out DifferentiablePhysics and FEMPhysics some > > time ago. Now I am wondering if I can use this to simplify my code. It > > is quite obvious that I can just subcalss FEMPhysics to implement e.g. > > NeoHooke material and attach that class to the FEMSystem. But as I can > > only attach one FEMPhysics class I wonder what is the best place for > > e.g. contact code? > > The original goal with the refactoring was to add a "SumPhysics" > subclass which would be attached to the FEMSystem and which would in > turn allow an arbitrary number of other DiffPhysics subclasses to be > attached to it. > > I got sucked into other things before I could finish that, but I'd be > happy to write the code later this week if I could talk you into doing > the testing.
That would be fine, I would definitly test it. > > > The other thing which is unclear to me are the QoI. Can it be used for > > projecting the stresses from quadrature points to nodes in > > postprocessing? Currently I am doing this in a seperate system. > > At the moment, all the library code using the QoIs assumes that your > final result is a small-enough-to-serialize set of scalars. You could > use the QoI assembly as a place to hook in other postprocessing, but > if you don't have those scalars then you don't have any need for the > library-level tricks with them (sensitivities, goal-oriented > adaptivity) and so there's probably no benefit to refactoring your > code to use them. Thanks for the clarification, looks like I don't need it. > > But postprocessing isn't the best place to project stresses either, > since that's outside the nonlinear solver loop and so limits you to > pseudo-transient solves, right? I wonder if I should add a > default-noop FEMPhysics::preassembly()/postassembly() method? I am currently doing quasi-static computations only, so there is no need for this from my side. Robert > --- > Roy ------------------------------------------------------------------------------ Time is money. Stop wasting it! Get your web API in 5 minutes. www.restlet.com/download http://p.sf.net/sfu/restlet _______________________________________________ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
