CAEBAT Open Architecture Software (OAS): Standardizing Input ORNL OAS Team

2Managed by UT-Battelle for the U.S. Department of Energy Review the structure for the Battery XML Schema and provide your feedback Once we have agreed on the structure, it is easy to populate the information in separate databases Based on your feedback, we will arrive at v1 of the input standard and start populating the data for some standard cases Outcome from today’s call

3Managed by UT-Battelle for the U.S. Department of Energy Exploit the hierarchical nature of batteries Consensus on XML as the standard for the input specification – Leverage many third-party tools – Facilitates interactive web-based input capability (GUI) Translators enable generation of CFD mesh from standard CAD packages Common set of tools to process, visualize, and analyze the input data Standardized Input

4Managed by UT-Battelle for the U.S. Department of Energy Materials Components – Anode, Cathode, Separator, Electrolyte, Current Collector, Tab, Insulator, Cooling, …. Cell sandwich – as a composition of above along with geometric information Cell – Prismatic or wound (spiral/flat) using above descriptors and additional geometric information Modules – Composed of cells and additional components such as Cooling, Insulator,…. Battery pack – Composed of modules, geometric specification and additional components such as cooling, insulator, ….. Hierarchical description of a battery

5Managed by UT-Battelle for the U.S. Department of Energy Updated the Excel sheets to work out the dependencies (near complete – I will send it after the meeting) First we converted the BDS tbm file to XML but there is lot of redundancy and overspecification – We can use some of those scripts to translate tbm files to our standard specification We tried to compose the battery in an hierarchical fashion starting from materials but model dependence broke the uniqueness Finally we arrived at a structure that seems to be a good compromise between complexity and ease-of-use that would satisfy all our requirements – We can now select the battery component, the model we want to employ and then specify the parameters – We can have as many of these battery components defined – Linked to Units for easy conversion later Evolution of the structure

6Managed by UT-Battelle for the U.S. Department of Energy Overall Layout XML Input File Front- End GUI Schema Database Schema controls the structure of the output, sanity checks, etc. Once these are finalized, the developers will never have to see it and users will never see the inner details. Database contains the properties, different realizations of the components at all levels – can be proprietary, etc. Xquery + Scripts Native Input File

7Managed by UT-Battelle for the U.S. Department of Energy BatteryML Schema

8Managed by UT-Battelle for the U.S. Department of Energy Cell-Sandwich Schema

9Managed by UT-Battelle for the U.S. Department of Energy Structure of SAMPLE XML output We have populated the properties for cell-sandwich simulations for three different models and now we need to finalize these inputs for one specific problem

10Managed by UT-Battelle for the U.S. Department of Energy Way to extract data from the XML file – Combine with scripts to convert to different software inputs Simple Example: xquery

11Managed by UT-Battelle for the U.S. Department of Energy Using schema and entering data through a free XML tool – One can customize the front-end GUI once we have a good back- end structure Look at the XML file Demo

12Managed by UT-Battelle for the U.S. Department of Energy Questions and Discussion