CAEBAT Open Architecture Software (OAS): Standardizing Input

ORNL OAS Team

2 Managed by UT-Battellefor 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

3 Managed by UT-Battellefor 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

4 Managed by UT-Battellefor 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

5 Managed by UT-Battellefor 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

6 Managed by UT-Battellefor 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

7 Managed by UT-Battellefor the U.S. Department of Energy

BatteryML Schema

8 Managed by UT-Battellefor the U.S. Department of Energy

Cell-Sandwich Schema

9 Managed by UT-Battellefor 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

10 Managed by UT-Battellefor 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

11 Managed by UT-Battellefor 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

12 Managed by UT-Battellefor the U.S. Department of Energy

Questions and Discussion