Re: [Libmesh-users] Hisotry variables

[gmail <a.m...@gm...>]

> On Sep 14, 2018, at 1:19 PM, gmail <a.m...@gm...> wrote:
> 
> Thanks Roy.
> 
>> On Sep 14, 2018, at 1:06 PM, Roy Stogner <roy...@ic...> 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