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. > --- > Roy Ata _______________________________________________ Libmesh-users mailing list Libmesh-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-users
