the precision of the values of the Gibbs energy #40
Comments
|
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. |
|
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. Best wishes! |
|
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. |
|
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. |
|
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. |
|
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. |
|
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. |
|
That's okay. I will try to verify the fix independently. |
|
I might locate the problem, which is from the mode.py. define model parameters' |
|
The way it's written is fine in Python 2 and 3 because of this line at the top: from __future__ import divisionMy guess is the culprit is here: Line 473 in 82410c5 0.1 is added to all the Curie temperatures to prevent a singularity. I should probably use a smaller value. |
|
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. |
|
Thanks for following up. I'll put together a fix and close this issue when I do. |
* Results in significant performance boost (30-50% in Cu-Mg) and ability to fit arbitrary models with MCMC. * We explicitly compile and pass callables around, which also improves performance especially in tight equilibrium for loops. * Use pycalphad Species, so pycalphad 0.7 or later is a hard requirement. * Non-dask/distributed schedulers are deprecated due to requirements in Pickleing SymPy objects. Work stealing must also be turned off by users in dask, however removing the fastcache package may be an alternate solution. This leads to breaking changes in the input files where we only support 'dask', 'None', and a path to a distributed 'scheduler.json' file. Closes pycalphad#40, pycalphad#22, pycalphad#53 * First pass at utilities for using the Model class * Cleanup of model class utilities * Move eqcallables above building phase models * Update eq_callables to not use the default dicts when not needed, pass models dict around * WIP debugging with time * FIX: Don't pass real symbol values to Model or PhaseRecord * WIP: Update lnprob test * WIP: Turn off parameter printing * ENH: Add message that building phase models may take time * MAINT: Remove timing code from lnprob * ENH: Remove dask delayed dbf and phase models * FIX: Make get_prop_samples compatible with Species * ENH: automatically wrap param_symbols in eq_callables_dict as Symbols from strings * FIX: Fix passing callables to calculate for single phase error * WIP: comment out some test code illustrating the multiproessing hack * WIP: Debug logging distributed client * WIP: force dask work stealing extension to be turned off. Work-stealing breaks SymPy code. Closes pycalphad#53 * Add back the logging to dask workers * Add lnprob times to debug * Add some documentation of multi phase fit, remove dask delayed * Add basic docs to estimate_hyperplane * ENH: Enable passing scheduler.json files as inputs Deprecates emcee and MPIPool. Everything runs through dask because cloudpickle is used and emcee multiprocessing and MPIPool can not use cloudpickle or custom serializers. * ENH: evaluate=False for Piecewise in refdata Huge performance bump, especially on SymPy 1.1.2dev versions where there were regressions. Will make the espei script much faster. * MAINT: Add work-stealing checks to dask scheduler with nice error message * MAINT: Bump pycalphad requirement to 0.7 * DOC: Update documentation for MPI schedulers * DOC: Update Mocking in docs
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
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!
The text was updated successfully, but these errors were encountered: