Re: [Libmesh-users] Hisotry variables

[Roy S. <roy...@ic...>]

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.

> 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?
---
Roy