How to disable the computing of inactivate element

[ZoeyChen1993]

Hi, I am using the element activate method in additive manufacturing, could anyone tell me if is there a way to disable the computing of the inactivate element, which means, the problem will not be solved in the element before it is activated?

[grmnptr]

I firmly believe that we don't use inactive elements when we compute residuals and jacobians. Maybe you could share why you think we do.

[ZoeyChen1993]

yes, actually the inactive elements belong to a block and the activate elements belong to another block, when I don't specify any kernel to the inactive block, output always suggests that there must be at least one kernel associated with this block, which means it has to be computed.

[GiudGiud]

This is a simple coverage check troubleshooting.

You can add in the problem: kernel_coverage_check = false to skip this

Then you should either print the matrix or look at the condition number if you believe there are active elements with no kernels there will be a bunch of 0s to deal with in the matrix

[zx1987]

Hi Peter @grmnptr and Guillaum @GiudGiud : We may not describe what we want to do clearly, so please allow me to use a MWE to demonstrate what we want to achieve. Say we want to simulate a heat conduction problem of a filament of ink being deposited onto a hot plate. We only want to solve the heat conduction problem in the ink. I have block 0 for air, 1 for ink, and use element activation to change air elements into ink elements, and desire to let the newly activated ink elements have an initial ink temperature. We tried the following:

Case 1: I only define variable T Temperature in the ink block, and diffusion and HeatConductionTimeDerivative kernels in the ink block. It will report the error "Each subdomain must contain at least one Kernel" indicating that I need to define a kernel in the air domain.

Case 2: I define the variable Temperature in both the air and ink block, and I need to define a kernel for the temperature in the Air domain. To make sure I get the correct initial condition for the newly activated elements, I just used a HeatConductionTimeDerivative for the air. Because this kernel is just a time derivative, so it is enforcing the air domain solve \dot T=0, meaning it will maintain an initial temperature after solving. Even though this gives me what I need, it is making the system much larger and with extra costs. I checked kernel_coverage_check = false, but it is for the entire domain, not just an air block. Is there a way to just enforce this for a block? I want to exclude the air elements from our calculation before being activated to be ink. Thanks.

Best,
Xiang

[GiudGiud]

Is T a nonlinear or an auxiliary variable?
Also keep in mind the auxkernel will execute all the time, so it will set the values again and again.
I m not sure if you are trying to stay at this initialized value

[zx1987]

Hi Guillaum @GiudGiud for further looking into this. T is already a nonliner variable that exists in block 1, and I was trying to initialize the T in the newly activated elements (activated from block 0 to be in block 1, which do not have T defined before activation) for only ONCE right after activation. So I should not use AuxVariable in this case based on your comments. When the simulation starts, the initial ink has T01=20 C, and the newly activated ink needs to be initiated to a different value T02=30 C. So the use of

[ICs]
    [T_IC]  #-- initial condition for T of the newly activated ink element
      type = ConstantIC
      variable = T
      value = 30
    []
[]

will not work as it will also set the initial condition of the ink at the start of the simulation to be 30 C.

So to be clear, I was trying to initialize the newly activated ink elements with a temperature value that I can define in the input file. Note that the elements do not have T defined before activation, and the temperature value to be initialized at the time of activation could be different from the initial condition of the ink elements that exist at the start of the simulation. Any further comments? Thanks.

Xiang

[GiudGiud]

At this point I feel you should either:

• modify the code to create a new option for initialization of new elements in a block (from some other variable for example, that has a different name, is defined everywhere and just stays constant)
• define T all over the domain and take the penalty in terms of DOFs. Those DOFs will have a very simple equation to solve so it may not be too bad?

[GiudGiud]

or new idea. A little bit of a hack but it should work

• You use T_IC for the ink at 30C for new elements
  and instead of an IC you use a transfer to override the IC and set the initial ink at 20 C.
  You can just create a dummy MultiApp simulation that just has a constant field on a mesh (could even be a 1x1 square if you have a constant field, and interpolate from that 1x1 cell mesh) and does not much more

[zx1987]

Hi Guillaum @GiudGiud: thanks for all the input, and I will first attempt to define T all over the domain, and create another initialization option.