ryanmrichard
commented
6 years ago @keipertk You can't do both (have the property types in SDE and switch the dependency order) because the property types depend on LibChemist.
I highly doubt that the SDE is going to be used in a generic fashion by people too far removed from computational chemistry. The furthest I can foresee is maybe some QED stuff. Without a massive marketing campaign it's not going to be discovered by people aside from its connection to NWX. That said the main motivation for moving the property types to outside SDE (likely LibChemist) is that it is conceivable that another package would want to use similar property types, but with their molecule and basis set classes. While it's nice to dream about a unified set of chemistry libraries, I think the reality is we're far away from that.
To answer the original question, the scope is to provide:
- a framework for building a package, such that the package can be used in an HPC setting
- a mechanism for encapsulating the algorithms of the package.
- support for dynamically extending the package
- ability to dynamically modify algorithms
- automatic logging of the results of an algorithm
- greatly simplified, if not fully automated, checkpointing/restart
Opening a separate to start a conversation about the points brought up by @ryanmrichard here
I think the property types do belong in SDE. I see the value of removing them and making the SDE generic if you want to expand the SDE user base outside of molecular simulations. But if we limit the scope to molecular science from the beginning, then we can make certain specializations (incl. PropertyTypes, default data) which make the SDE easier to use for people in our fields - and a one-stop shop for developing molecular science Modules.
I am in favor of switching the dependency order with LibChemist to implement things like system partitioning as Modules. Can all of LibChemist be implemented as Modules?