Hi Michel,
The philosophy of PyCalphad is a big question 🙂
I can give my own perspective as one of the core team members, but I don't speak for everyone on the team.
PyCalphad is more and more used in the community, especially by those who are not on the core team. We want to continue to meet those needs, and also the needs of the existing and future projects that depend on PyCalphad, which currently include:
-
ESPEI for Calphad database development and uncertainty quantification
-
Kawin for KWN-based precipitation modeling
-
OpenIEC for computing interfacial energies
In that regard, our immediate next steps focused on stabilizing PyCalphad with a 1.0 release, which we are tracking in a
GitHub Project. Longer term, we are taking actions to continue to be able to sustain and support the open-source ecosystem developing around PyCalphad.
On the technical side, we want to continue our high level of support for things that are well
established (models implemented in TDB and DAT files), but also provide a
platform to adapt and progress. We see one of PyCalphad's strengths being in its object-oriented design. Concepts like the Database object allow for the computational representations of Calphad to be decoupled from on-disk representations (TDB, DAT, XML files). The Model object allows for new models to be developed without changing any of the code in the Gibbs energy minimizer, as we recently achieved when we implemented the modified quasichemical model in the quadruplet approximation without modifying any code in our minimizer. Our goal in the design of PyCalphad is to make it easy use and extend to solve any problem.
Cheers,
Brandon