IBAMR / IBAMR

An adaptive and distributed-memory parallel implementation of the immersed boundary (IB) method
http://ibamr.github.io/
Other
347 stars 144 forks source link

New subclass for solving energy equation with phase change terms in conservative form #1216

Open Raamkrishnan opened 3 years ago

Raamkrishnan commented 3 years ago

I am working on modeling the phase change problems. For that, I want to solve the energy equation with phase change terms in conservative form. I am thinking of writing one subclass derived from AdvDiffSemiImplicitHierarchyIntegrator class. In AdvDiffSemiImplicitHierarchyIntegrator class, we solve the advection-diffusion equation in non-conservative form. Can I proceed further with this design? Please let me know if there are any better suggestions.

boyceg commented 3 years ago

Can you point me to a reference for what you want to implement?

boyceg commented 3 years ago

Also, you should be able to handle the convective term in either advection or conservative form already — it depends on the way the convective differencing operator is implemented.

Raamkrishnan commented 3 years ago

Phase_change.pdf Eq. 13 in the attached file is the one I want to implement. Here, density and specific heat are spatially varying quantities and are updated every time step based on the liquid fraction (g). The liquid fraction is updated iteratively every time step. The complete formulation on updating the liquid fraction can be found in https://www.tandfonline.com/doi/abs/10.1080/10407799108944962.

boyceg commented 3 years ago

Sorry for the delay. Instead of making a subclass, could you make a custom "convective operator"? This is the approach we used for implementing support for polymeric fluids, which use the so-called upper convective derivative instead of the usual convective derivative in determining the dynamics of the polymeric stress. This should require much less new code than a subclass.

boyceg commented 3 years ago

@abarret, what do you think?

boyceg commented 3 years ago

It might be worth spending some time thinking about whether there are changes to interface to AdvDiffSemiImplicitHierarchyIntegrator that would make it easier to specify different physics models.

abarret commented 3 years ago

Sorry for the delay. Instead of making a subclass, could you make a custom "convective operator"? This is the approach we used for implementing support for polymeric fluids, which use the so-called upper convective derivative instead of the usual convective derivative in determining the dynamics of the polymeric stress. This should require much less new code than a subclass.

You should be able to implement everything in a convective operator. The time derivatives might be tricky, but I would suggest using a forcing function for that.

An issue might be that there's not a notion of "time" in a convective operator. If the operator has quantities that change over time that are not the velocity or advected quantity, then it's difficult to determine at what time to evaluate them. There are a couple of workarounds. First, the "state" variables (g, C, rho, T in your document, I think?) can be grouped into a single SAMRAI variable, which probably should be done anyway if you're trying to conserve quantities. Second, you can register a velocity function that modifies the velocity to include any time-dependent quantities not stored in the state variable.

boyceg commented 3 years ago

It might be necessary to generalize the API.

@Raamkrishnan, can you think about whether you can use the existing API to implement this by providing implementations of a convective operator, velocity functions, and forcing functions? If not, can we try to extend the API? I think it will be less code, easier to maintain, and easier to couple to other models.

Raamkrishnan commented 3 years ago

Thank you @boyceg and @abarret. We dropped the enthalpy-porosity technique that I attached earlier. We are working on implementing a consistent and conservative approach. I will try to make use of the existing API with an additional custom convective operator and/or forcing function classes. If significant changes are required in the existing API, I will post here for your suggestions.