> On Sep 14, 2018, at 1:19 PM, gmail <a.mesgarne...@gmail.com> wrote: > > Thanks Roy. > >> On Sep 14, 2018, at 1:06 PM, Roy Stogner <royst...@ices.utexas.edu> wrote: >> >> >> On Fri, 14 Sep 2018, gmail wrote: >> >>> I’ve recently added plasticity with implicit integration to my code. >>> This requires keeping track of so called “history variables” (i.e. >>> internal parameters of plasticity such as back stresses, equivalent >>> plastic strain,..) on each quadrature point. I have come up with a >>> crude work around that works currently simply defining each history >>> variable for each quadrature point (in a uniform mesh) as a DG0 >>> variable. I was wondering: >>> 1) if there’s a better way to do this within the libMesh framework? >>> i.e., a way to attach to a NonlinearImplicitSystem an array of N >>> variables (where N is not necessarily the number of knowns in the >>> system) with a correct parallel layout. >> >> Generally the best thing to do for auxilliary variables is use a >> vector in a separate ExplicitSystem... >> >> But the reason to do it that way is so that they're kept straight for >> you through repartitioning, ghosting, refinement and coarsening, etc. >> In this case, with the DG0 variables idea, you do get repartitioning >> and ghosting handled. >> >> But if you have a variable per quadrature point, you don't get the >> AMR/C benefits, because the quadrature point on a child element won't >> be at the same place as the parent point was and probably shouldn't >> have the same value. If you're never going to refine or coarsen >> that's fine. If you are, and you're using simplices, then you could >> pick a MONOMIAL basis order that matches your implicit system's >> quadrature rule, interpolate that onto quadrature points, and use >> that. If you're not on simplices, but you're using a low p, you can >> probably get an L2_LAGRANGE order to match. If you're using high p >> and not on simplices then we probably don't have anything that can >> help you with AMR. > > OK. I’m sticking with my DG0 implementation then. I already do projections of > these variables when I want to write the output. > >> >>> 2) Even though I set the hideoutput flag on, on the ExplicitSystem >>> that contains these variables, it’s still being written to when I >>> call ExodusII_IO::write_timestep(). >> >> That... looks like an unimplemented feature that isn't marked as >> unimplemented? Looks like hide_output is only respected by our >> XDR/XDA I/O, and for other formats we have a container-of-strings >> system_names variable to accomplish the same task? That seems... >> inconsistent. John and I probably should have noticed that before >> accepting https://github.com/libMesh/libmesh/pull/611 >> >> I suppose it would make sense to, when system_names is left NULL, >> check hide_output() instead of defaulting to all systems? > > I see, I thought I might be missing something. I will try to create a patch > that does the same in ExodusII_IO.
Here’s my embarrassingly simple patch <https://www.dropbox.com/s/udlhiwpqmevma4k/libmesh-equation_system-hide_output.diff?dl=0>. Ata > >> --- >> Roy > > Ata _______________________________________________ Libmesh-users mailing list Libmesh-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-users
