# the precision of the values of the Gibbs energy#40

Closed
opened this issue Feb 29, 2016 · 12 comments
Closed

# the precision of the values of the Gibbs energy #40

opened this issue Feb 29, 2016 · 12 comments
Labels

### 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! The text was updated successfully, but these errors were encountered:

### 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 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 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 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.

added the bug label Mar 2, 2016

### 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 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 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 commented Mar 4, 2016

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

### 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 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:

Line 473 in 82410c5

 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 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 commented Mar 5, 2016

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

closed this as completed in ``` 2537f23 ``` Mar 5, 2016
added a commit that referenced this issue Aug 4, 2016
``` DOC: Research notebook for gh-40. ```
``` b938e6a ```
added a commit to bocklund/pycalphad that referenced this issue Aug 17, 2021
``` ENH: Use Model class (pycalphad#50) ```
``` 506a037 ```
```* 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.

* 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.

* Add lnprob times to debug

* 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```