On Tue, 15 Feb 2011, Robert wrote: > when starting to use FEMSystem I discovered some strange behaviour which > looks like a bug: > The FEMContext has a attribute request_jacobian which I assumed to have > the same meaning as the parameter to e.g. > FEMSystem::side_constraint(..). But it the value in FEMContext never is > updated to reflect the current state of request_jacobian. So either > remove request_jacobian from FEMContext or set it to the same value as > the parameter.
It's definitely a bug, but from the interesting subcategory of "incomplete design decision". When I was initially refactoring DiffSystem it seemed natural to move request_jacobian from a separate parameter to just another part of the DiffContext information that gets passed to physics evaluation methods. But I was doing the refactoring in stages, and never got to that stage... and then later we made DiffContext an independent utility class: it's now useful in non-DiffSystem code and it's required by RBSystem code. In the most generic non-DiffSystem case, a "request_jacobian" at the element assembly level wouldn't make sense, since in the most general case the library doesn't do anything at the element assembly level. David, would you have any use for DiffContext::request_jacobian in the RBSystem code? If not, then my first inclination is to just remove it. > Another thing I like to know is whether there is some mechanism to store > additional information for nodes or quadrature points so it gets > distributed and reassembled when using MPI. I intend to use this e.g. to > for store the progress of damage or other internal state of the material. We generally prefer storing this sort of information where possible as solution fields in an appropriate finite element basis (e.g. isoparametric C0 for nodal data, monomial discontinuous for quadrature point data) so that both parallelism and adaptivity work automatically. Use a separate ExplicitSystem to keep the extra data out of your main solve. (unless you really want a fully implicit tightly coupled solve for it) --- Roy ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
