Controls system (moving dofs)

[mangerij]

Check these boxes if you have followed the posting rules.

• Q&A General is the most appropriate section for my question
• I have consulted the posting Guidelines on the Discussions front page
• I have searched the Discussions forum and my question has not been asked before
• I have searched the MOOSE website and the documentation does not answer my question
• I have formatted my post following the posting guidelines (screenshots as a last resort, triple back quotes around pasted text)

Question

Is it possible to implement the following logic in Controls based on an AuxVariable that is 0 or 1 as a function of time? I want the only consider the Kernels/Materials/etc of the moving mesh in the below image. The mesh itself stays fixed, it is only the degrees of freedom that would be turned off/on based on the Controls logic. I looked a bit in the repository and I do not see any clear examples of tests where Controls logic is based on an AuxVariable but also maybe I missed where.

Ideally, I want to track a moving wavefront but I do not want to consider DOFs in regions where the wavefront does not exist. In this sense, the PDE governing the wave will be killed based on the AuxVariable. This would give an enormous speed up for a planned project. I have been using Controls a bit with block restriction - very useful for a number of scenarios. But for this situation, I would need to have many blocks and their off/on status would be step-wise.

[GiudGiud]

Hello

I think MeshModifier, notably the ElementVarThresholdSubdomainModifier, might be an easier way forward here.
You can change the subdomains between an inactive and an active subdomain as time progresses.

The bigger difficulty is how to initialize the variables. You will definitely need to code up your own behavior either in the UO
OR in a "Corrector" object (just another UO) that modifies the nonlinear solution

the MeshModifier have some nodal patch recovery-based and IC-based initialization behaviors for newly activated elements, but that wont be enough for what you want

[GiudGiud]

@hugary1995 fyi one of the potential needs for DOF value initialization

[hugary1995]

Yeah, what OP described is EXACTLY what element subdomain modifiers do.

In this case initialization is actually easy -- just do zero initialization -- based on the assumption that "inactive" domains are outside the wavefront.

Though if we step further back, honestly speaking this is what adaptive mesh refinement is for.

[GiudGiud]

Alternatively,
can you just move the mesh (using a MeshModifier still)? Are you solving for displacements? Moving the mesh elements naturally moves the variable values

[mangerij]

well the thought here is that the entire computation domain will be the output of another simulation (which is a phase field problem coupled to elasticity).

Then, the wavefront is initiated and I would need to track its dynamics as it moves through the solution of the previous calculation.
This works just fine without any mesh modification or Controls, it is just slow.

(yes there is elasticity involved here)

[hugary1995]

For just elasticity, adaptivity is the way to go. Use the (function of) phase field variables as the indicator.

[hugary1995]

Make sure you use the total formulation rather than the incremental formulation from solid mechanics.

[mangerij]

We will see; this is quite a few months from even being looked at - thinking ahead here.

If I had an .e file, with the solution of the ground state (let's say uniform hex8 with 0.5 resolution), that I then restart, I should be able to coarsen it significantly before the wave equation problem starts to evolve?

This is my issue here. My understanding is that max coarsening would be the 0.5 size elements if I do it this way and then there would be no way to make them larger.

[GiudGiud]

If I had an .e file, with the solution of the ground state (let's say uniform hex8 with 0.5 resolution), that I then restart, I should be able to coarsen it significantly before the wave equation problem starts to evolve?

A priori no. You can coarsen elements easily when having first started from a coarse mesh, refined it, and saved it in a Checkpoint file. .e file is Exodus and this is not supported.
If you were to use the CoarsenMeshGenerator, it would be able to coarsen a previously refined mesh, but it is not used much, and you would need to load the mesh again with a SolutionUO to fill in the solution in the newly coarsened mesh.

Or did you mean refine instead of coarsen by any chance? That changes everything and things work better with refinement.