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

the precision of the values of the Gibbs energy #40

Closed
zhongjingjogy opened this Issue Feb 29, 2016 · 12 comments

Comments

Projects
None yet
2 participants
@zhongjingjogy

zhongjingjogy commented Feb 29, 2016

Hi,

Recently, I did some comparison of the values of the Gibbs energy from Tabulate module of the Thermo-Calc, pycalphad and my reader, which shows there are slightly difference between the values.

For the Gibbs energy of the FCC_A1 in the Al-Ni system(with magnetic ordering), the conditions are set as T = 873.15K, p = 101325, x(al) = 0.01 and the values are listed as following

  • TC: -3.84128821E+04 (R = 8.31451)
  • pycalphad: -38412.9016962598 (R = 8.31451) and -38412.9011777456(R = 8.3145)
  • mine: -38412.8820655441 (R = 8.31451)

It seems that the value of the gas constant do make a difference. But such difference might not be as larger as the one between the pycalphad and the TC.

Just report this and hope it might be helpful.

Best wishes!

@richardotis

This comment has been minimized.

Collaborator

richardotis commented Feb 29, 2016

Hi Jing,

Thank you for your message. The difference is about 20 mJ/mol, which is below the current convergence limit for pycalphad's solver. In the future pycalphad's equilibrium results will be accurate to 1mJ/mol.

In the specific case you mentioned, since R is only specified to 6 significant figures, I would only compare the first 6 significant figures from the results. If you do that, they are the same.

@zhongjingjogy

This comment has been minimized.

zhongjingjogy commented Mar 2, 2016

Hi Otis,

Sorry for not mention about that the values above are directly from the Model.ast by substituting the variables in the Gibbs energy expression, instead of values from the equilibrium results. I have figured out what might be happening anyway.
There are contributions from the magnetic ordering in the Al-Ni system. I calculated the values of the Gibbs energy for the FCC_A1 phase in Al-Cu system, and no difference is observed. It seems that model for magnetic contribution in pycalphad (W. Xiong, 2011) is bit different from the one in Thermo-Calc in p version (IHJ model, I guess as I get the same values by using IHJ model.).
I have no idea about what kind of model for the magnetic ordering is using by a specific tdb file. Maybe the model (W. Xiong, 2011) is quite new and it failed to model the databases that were established before that. Anyway, I would have a look at whether Xiong's model is consistent with the IHJ model, or not.

Best wishes!

@richardotis

This comment has been minimized.

Collaborator

richardotis commented Mar 2, 2016

Thank you again for looking into this so carefully. The result is indeed interesting. pycalphad uses the IHJ model for magnetism by default, but there are some known precision issues due to the large exponents. It would be interesting to see the exact conditions you looked at so I can follow up.

@richardotis

This comment has been minimized.

Collaborator

richardotis commented Mar 2, 2016

To be clear, I copied the IHJ model from Wei Xiong's 2011 paper where he discussed his new model, but he had the older IHJ model in the background section.

@richardotis richardotis added the bug label Mar 2, 2016

@richardotis

This comment has been minimized.

Collaborator

richardotis commented Mar 2, 2016

So the Curie temperature of pure Ni is near 627 K, which is well below the calculation temperature of 873 K. I think this is due to pycalphad adding 0.1 K to the value of the computed Curie temperature to prevent singularities when the Curie temperature goes to zero. This changes the value of T/Tc which is used to do the calculation. I will do some thinking about how to address this. It's better to be off by 20 mJ/mol than for the calculation to fail, I think.

@richardotis

This comment has been minimized.

Collaborator

richardotis commented Mar 2, 2016

I can't reproduce your exact result because I don't have the same Al-Ni database as you, but I can reproduce a ~10mJ/mol difference by adjusting the 0.1 K numerical tolerance parameter I mentioned in the previous comment. If you are willing to provide your database or another database with the same issue, I can push a fix for the issue.

@zhongjingjogy

This comment has been minimized.

zhongjingjogy commented Mar 4, 2016

Sorry for the delay, but I still have something else in my hand. Also, I'm not authorized to post the tdb file here. But I'm still working on this problem and I hope I would figure it out by the end of this weekend.

@richardotis

This comment has been minimized.

Collaborator

richardotis commented Mar 4, 2016

That's okay. I will try to verify the fix independently.

@zhongjingjogy

This comment has been minimized.

zhongjingjogy commented Mar 5, 2016

I might locate the problem, which is from the mode.py.
'

define model parameters

    p = phase.model_hints['ihj_magnetic_structure_factor']
    A = 518/1125 + (11692/15975)*(1/p - 1)

'
It's no doubt that such an expression will cost the lost of precision for the type cast in the integer division. And A would always be zero.

@richardotis

This comment has been minimized.

Collaborator

richardotis commented Mar 5, 2016

The way it's written is fine in Python 2 and 3 because of this line at the top:

from __future__ import division

My guess is the culprit is here:

tau = v.T / (tc + 0.1)

0.1 is added to all the Curie temperatures to prevent a singularity. I should probably use a smaller value.

@zhongjingjogy

This comment has been minimized.

zhongjingjogy commented Mar 5, 2016

Yes, that's true. I modify the integer to be float manually and pycalphad generate the same result as before. And I take away that 0.1 and pycalphad just gives the same result as thermo-calc.

Anyway, this could be the end of this issue.

@richardotis

This comment has been minimized.

Collaborator

richardotis commented Mar 5, 2016

Thanks for following up. I'll put together a fix and close this issue when I do.

richardotis added a commit that referenced this issue Aug 4, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment