search

idaholab / moose

Multiphysics Object Oriented Simulation Environment
https://www.mooseframework.org
GNU Lesser General Public License v2.1
1.78k stars 1.05k forks source link

Diffusion Controlled Evaporation with Displacement / Node Deactivation Approach #21579

Open hugary1995 opened 2 years ago

hugary1995 commented 2 years ago

Discussed in https://github.com/idaholab/moose/discussions/21443

Originally posted by **AndrewFalkowski** June 28, 2022 I am looking to model a diffusion controlled evaporation process with mass loss resulting in uniform material recession at the surface; however, I am struggling to come up with a good approach for modeling the recession and shifting of the boundary position with material loss? A coupled displacement condition seems overly complicated and might create errors arising from the displaced mesh. Alternatively, I was considering node deactivation, but I am not sure how to then shift the applied boundary condition. If I could get some advice on an approach to this, that would be great!
dschwen commented 2 years ago

@lindsayad worked on something similar with his laser melt pool. Displacement of the boundary nodes, plus a diffusion equation on the displacement variable. Just make sure to advect the concentration fields in the opposite direction to avoid moving material with the mesh.

hugary1995 commented 2 years ago

I have discussed this with @loganharbour and @GiudGiud on slack, and have been thinking about this for a while. Right now the ElementSubdomainModifiers are doing more than what's suggested by their names -- they not only modify element subdomains, but also maintain a moving boundary/interface. I think the forward looking "correct" fix is to let the ElementSubdomainModifiers "do less", and let another run-time mesh modifier to maintain the moving boundary/interface.

On a related note, right now the moving boundary is added on both sides of the interface. There's nothing wrong with that, but for maximum flexibility we should give the two sides of the interface different names, so that we could handle problems like the one mentioned in the linked discussion above.

@GiudGiud also mentioned that there might some work going on in the next FY on run-time meshgenerators/meshmodifiers.

GiudGiud commented 2 years ago

@eshemon and @permcody will know more about planned work on run-time execution of MGs.