Initialize variable value of newly activated element

[keassyguang]

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

Hello everyone,
I am currently working on a additive manufacturing process simulation project using the MOOSE. I got some problems when I tried to initialize/reinitialize variable value of newly activated elements.

According to the MOOSE documentation on ElementSubdomainModifier: https://mooseframework.inl.gov/source/meshmodifiers/ElementSubdomainModifier.html

By default, all elements that change subdomain ID are reinitialized to the new subdomain's initial condition.

The left part of the below picture shows a temperature initialization result of a newly added layer (Layer 2) within the ABAQUS software. For the newly added layer, Layer 2, the bottom nodes of this layer are shared with Layer 1 (top nodes of layer 1). ABAQUS initializes the temperature of Layer 2 by setting the specified value, except for these shared nodes, as the temperature of these nodes is kept the same as the value at the end of Layer 1.

As for MOOSE, based on my observations, since all elements move from the inactivated domain to the activated domain, all the nodes are initialized. For those shared nodes, it seems that MOOSE overrides their previous/existing values directly with the specified value. (If I am wrong, please correct me).

I know there might be physical meaningful for both these two initializtion methods. But what should I do if I want to achieve the same initialization as in ABAQUS?

[GiudGiud]

@hugary1995

We have not implemented this behavior afaik.
We can use the IC object to initialize, and can skip reinitialization based on the new and old subdomains these elements get assigned to.

In the current setup, I dont think this is hard to implement. I would do it with a NeighborElementsFunctorIC, which would be an IC that looks at the neighbor element values, possibly with a multi-layer stencil, and computes the average of neighbor values within the same subdomain (the new subdomain of the element being switched)

[keassyguang]

Do you mean that I create a new IC object since I didn't find an existing IC object named "NeighborElementsFunctorIC"?

[GiudGiud]

yes

[hugary1995]

You are right about variables being initialized to their initial conditions. You can selectively initialize certain subdomains using the reinitialize_subdomains parameter. Quoting the parameter description

By default, any element which changes subdomain is reinitialized. If a list of subdomains (IDs or names) is provided, then only elements whose new subdomain is in the list will be reinitialized. If an empty list is set, then no elements will be reinitialized.

As to your second question:

As for MOOSE, based on my observations, since all elements move from the inactivated domain to the activated domain, all the nodes are initialized. For those shared nodes, it seems that MOOSE overrides their previous/existing values directly with the specified value. (If I am wrong, please correct me).

I don't believe that's the case, at least your observation is not the intended behavior. However, I see a potential issue when inspecting the source code. In ElementSubdomainModifierBase::applyIC method, we have the following call

  _fe_problem.projectInitialConditionOnCustomRange(reinitializedElemRange(displaced),
                                                   reinitializedBndNodeRange(displaced));

It calls the projectInitialConditionOnCustomRange provided by the framework on the newly reinitialized elements and boundary nodes. However, in your case where you are interested in reinitializing nodal variables, this might be forcibly reinitializing the "shared" nodes (in your original description).

I agree this is an issue, and we should at least allow users to control the behavior on shared nodes.

[keassyguang]

where is the "point used to plot"? Is that a node? Or a Qp? or a point on a side?

It is a point on the top surface of layer 1, and I think it is also a node. A point on the top side of layer 1.

[GiudGiud]

@hugary1995 Is there an option to get the ICs to apply (when triggered by a subdomain change) on the new elements but not on the boundary nodes?
Or maybe this is already the default behavior?

[hugary1995]

That is the intended behavior, but it is not happening. That's exactly what I want to fix.

[GiudGiud]

Thanks. I should have re-read the entire thread!

[keassyguang]

I cannot sample the values with the SideValueSampler because the top_side moves from the top of layer 1 to the top of layer 2 when layer 2 is activated. So I use the LineValueSampler instead. On the left is time=4s and on the right is time=4.01s. The results are almost the same as before.