Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Total free energy going UP in Cahn-Hilliard simulation #5595

Closed
dschwen opened this issue Aug 20, 2015 · 11 comments
Closed

Total free energy going UP in Cahn-Hilliard simulation #5595

dschwen opened this issue Aug 20, 2015 · 11 comments
Labels
C: Modules T: defect An anomaly, which is anything that deviates from expectations.

Comments

@dschwen
Copy link
Member

dschwen commented Aug 20, 2015

We have several reports of phase field simulations showing an increase in the total free energy. This should not happen. I was able to reproduce this issue with a simple input file (that utilizes ElasticFreeEnergy). I'm investigating this further.

Ping @tonkmr (as this may involve the TotalFreeEnergy Auxkernel)

@dschwen dschwen added T: defect An anomaly, which is anything that deviates from expectations. C: Modules labels Aug 20, 2015
@permcody
Copy link
Member

Dude - you've discovered free energy! Forget nuclear power, dump all your money into this!
💰

dschwen added a commit to dschwen/moose that referenced this issue Aug 20, 2015
@dschwen
Copy link
Member Author

dschwen commented Aug 27, 2015

One issue are undeclared variable dependencies. This is an error a user can easily make. E.g. For a free energy F=c*V, where V is a chemical potential AuxVariable, we need to specify args = V to the CahnHilliard kernel. This is required for the kernel to 'see' the gradient of F due to the gradient of V.
I think my first move will be to add a runtime check that looks for potentially missing args. I cannot do that at construction time to populate args automatically, but I think I can at least add a check at initialSetup time to compare the set of existing derivative material properties and the specified args.
However, @tonkmr, there is another issue: The elastic energy depends on strain and free energy gradients can be introduced by strain gradients! I don't yet know how to compute the strain gradient yet and use it in the CahnHilliard kernel to generate the propper driving force. This is a huge issue right now.

Tagging @laagesen

@dschwen
Copy link
Member Author

dschwen commented Aug 27, 2015

Let's look at a simple free energy, which is basically a ramped chemical potential

F=c*V, V~x

And lets assume kappa=0, M=1 so that the CH equation reduces to

dc/dt=\nabla^2 dF/dc

Intuitively we'd expect a diffusion to the negative x direction, where the chemical potential is smallest. But looking at the CH equation the driving force seems to be zero! As

dF/dc=V, grad V=const, div const = 0

But in the weak form one differential operator is shifted to the test function and we get

drivingforce

Which does yield the anticipated result of evolving the concentration to shift to lower chemical potentials. Needless to say that I am confused.

Quicklatex.com

@jwpeterson
Copy link
Member

@dschwen may be missing the boundary term,

dschwen added a commit to dschwen/moose that referenced this issue Aug 28, 2015
dschwen added a commit to dschwen/moose that referenced this issue Aug 28, 2015
dschwen added a commit to dschwen/moose that referenced this issue Aug 28, 2015
dschwen added a commit to dschwen/moose that referenced this issue Aug 28, 2015
@SudiptaBiswas
Copy link
Contributor

Is this issue resolved? I noticed while coupling PhaseField and TensorMechanics, elastic energy goes up as applied load increases. This eventually leads to increase in total free energy and Cahn-Hilliard is not able to reduce it (probably tensor mechanics is governing). Is there anything needs to be taken care of in this case?

@dschwen
Copy link
Member Author

dschwen commented Sep 2, 2015

We are working on this. Currently a term is missing in the elastic free energy derivatives. File this issue for further updates.

@SudiptaBiswas
Copy link
Contributor

Thanks for the update @dschwen. I will keep an eye on this issue. Let me know if I can contribute to this in any way.

@dschwen
Copy link
Member Author

dschwen commented Sep 9, 2015

@SudiptaBiswas we are working on this at #5631

@SudiptaBiswas
Copy link
Contributor

Thanks @dschwen , I figured that out.

@dschwen
Copy link
Member Author

dschwen commented Sep 28, 2015

Possibly related to not using displaced meshes. Cannot check due to bug #5750.

@dschwen
Copy link
Member Author

dschwen commented Oct 30, 2015

I'm closing this, as we identified and fixed a number of issues here. Please open a new issue if this problem is encountered with a specific simulation setup.

@dschwen dschwen closed this as completed Oct 30, 2015
dschwen added a commit to dschwen/moose that referenced this issue Oct 15, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C: Modules T: defect An anomaly, which is anything that deviates from expectations.
Projects
None yet
Development

No branches or pull requests

4 participants