Menu ▾ ▴

CAEBAT

Gregory M Lyon Scott Forest Hull II Dasha
There is a newer version of this page. You can find it here.

This page describes the structure and usage of CAEBAT, building instructions, how to run an example, and how it is related to NiCE.

Introduction to CAEBAT

Computer-Aided Engineering for Electric Drive Vehicle Batteries (CAEBAT) is an open-architecture framework that integrates multi-physics and multi-scale battery models. After experimental validation, these simulations can be used for research, design, and manufacturing.

OASFramework

The OAS modeling framework integrates all the physics necessary for development of realistic and predictive battery performance and safety models. This framework uses a Python scripting language, and controls the battery state through component and state adapters.

The component adapters interact with the components by preparing the necessary inputs to run the components and by scheduling the component runs. The state adapters interact with the battery state file by updating all the necessary information about the battery state and the methods for coupling the components. The Battery state file is the core for passing data between components.

VIBE

VIBE expands to Virtual Integrated Battery Environment. The OAS framework, along with physics and support components and the adapters constitute the VIBE. The current components are electrochemistry, thermal, electrical, and cost model.

Other

The data for CAEBAT is in a 

tar.gz

file available upon request.

The Battery Markup Language (Battery ML) provides standardized format for the definition of all the necessary information.

The BatteryML Schema controls the structure of the output, and it uses a relational data model to stay flexible and avoid data duplication.

CAEBAT in NiCE

We plan to integrate CAEBAT into NiCE as a plugin so we have a tool for simulating battery codes. NiCE will simply use its current tools to run CAEBAT, behind the scenes.

These are a compiled effort based on the meeting of 3/21/2013

We will design CAEBAT into three different pieces:

  • Model
  • Launcher
  • Analysis (tentative)

Model

There are multiple pieces to this particular module and will probably be the most complex. The CAEBAT program will require 3 types of input files in varying degrees of format and complexity:

A.) The 

workstation.config

. This will probably be pre-generated under the hood by NiCE or another script and not be visible in the model builder.
B.) The 

Chartran.config

file. This is a configuration setup file for the simulation. This will be pre-generated with NiCE's XML format for creating the model, and the input model will be generated in the listed format (a combination of key/value pairs with bracketing). Part of the k/v pair parsing is in NiCE, but will need to investigate K/V parsing for tables and 

MasterDetailsPairs

.
C.) The "model" 

BatML.file

. The schema will be provided by the CAEBAT Folks where we will investigate a way to generically handle the schema file in order to produce the GUI layout in the model, and then transform the values inputted into the schema enforced xml file.

Launcher

The basic launcher in development will suffice, but will investigate looking into adding Entries into the JobLauncher to handle multiple input files.

Analysis ("Pretty Pictures")

AUTOCAD or other visualization tools to show the results of the simulation.

The standing basis for the model will be CAEBAT CASE 4 model.

Building CAEBAT

OASFramework

To create the OASFramework :

1. Create a directory 

CAEBAT

and cd to that directory

2. Check out the source code from the repository using following command: 

svn checkout http://svn.code.sf.net/p/ipsframework/code/trunk OASFramework

3. To build the library, use the following terminal commands:

  • cd OASFramework

  • mkdir build

  • cd build

  • ccmake ..

    • Press 'c' to configure the build, then 'e' to exit
    • Edit the key 'CMAKE_INSTALL_PREFIX' to enter the bin installation directory 
      /PATH/TO/OASFramework/install
    • Press 'c' to reconfigure the build
    • Enter 'g' to generate and exit from 
      ccmake

  • make

  • make install

VIBE

1. Pre-install HDF5 and 32bit CGNS

For CGNS: in ccmake enable Fortran, HDF5 and tests. Also enable the tools if you wish to query the output.

If you want to perform optimization or parameter sweep, you need to also install DAKOTA (Design Analysis Kit for Optimization and Terascale Applications).

2. Untar the VIBE compressed file (

tar xzvf VIBE.tar.gz

) into the CAEBAT directory.

  • cd VIBE/trunk/components/config/

  • ln -sf makeconfig.gnu makeconfig.local

  • cd ../

(go back to 

    components

directory)
* make

    • Configure the installation location to 
      /usr/bin/install

and remember not to end with a "/"
* make install

(this will install everything in the bin directory under components)

DATA

1. Untar the DATA directory (

tar xzvf CAEBAT-DATA.tar.gz

) into the 

/CAEBAT directory

.

Running a Simulation with CAEBAT

In order to run this, make a new directory in CAEBAT called 

RunExample

. When going through these steps remember not to have "/" on the end, and that "Library" must be spelled correctly. Create the following directories in 

RunExample
  • Data
  • Results

  • Physics
    Move the following files into

    RunExample

  • Configuration files: 
    thermal_chartran_cell_twoway.conf

and 

    workstation.conf

Move the following files into 

RunExample/Data/dualfoil/
  • Data: 
    li-ion-ebar.in

and 

    dualfoil5.in

Configure the 

workstation.conf
  • Change 
    PHYS_BIN_ROOT

= 

    /RunExample/Physics
  • Change 
    DATA_ROOT

= 

    /RunExample/Data

Next, Configure the 

thermal_chartran_cell_twoway.conf
  • Change 
    CAEBAT_ROOT

= 

    /CAEBAT/VIBE/trunk/components
  • Change 
    SIM_ROOT

= /RunExample/Results</big></pre>

Next, do sourcing to use the 

cgns

library, by using the following commands:

  • vi ~/.bash_profile
    • Create a new Library by typing the following below your current library: LD_LIBRARY_PATH=/opt/cgns-3.1.3-i686_gcc-4.4.6/lib:$LD_LIBRARY_PATH
  • Then you must restart the bash profile for this change to take effect by: . ~/.bash_profile
  • Check that this library assignment worked by using: echo $LD_LIBRARY_PATH
  • Every time the terminal is closed the ". ~/.bash_profile" must be run to reassign this library.

Now, to actually run the example use the following command while in /RunExample.

/CAEBAT/OASFramework/install/bin/ips.py --simulation=thermal_chartran_cell_twoway.conf --log=temp.log --platform=workstation.conf -a

In order to run it again, the /RunExample/Results/work directory must be emptied each time between runs.

Input Parameters

This is a list of all the values that the user may like to change.

In workstation.conf:

HOST = allu1, which is an arbitrary user set description of the host.

MPIRUN = eval, which is the only allowed value. "mpirun" is a shell script used to launch a job with mpi. 

**Resource detection method**

NODE_DETECTION = manual

Description: This determines whether the user chooses the finer options in the manual allocation description section, or simply chooses a preset node detection option.

Allowed Values: checkjob | qstat | pbs_env | slurm_env [Default Value = manual] 

**Manual allocation description**

TOTAL_PROCS = 2, NODES = 1, PROCS_PER_NODE = 2

Description: This only applies when NODE_DETECTION = manual, and allows the user to choose how they want to process on their nodes.

Allowed Values: These are shown with their default values, and can have all integer values up to the platform's capabilities. 

**Node topology description**

CORES_PER_NODE = 2 and SOCKETS_PER_NODE = 1

Description: A node is a group of sockets, which are groups of cores that are single processing units capable of performing computations.

Allowed Values: These are shown with their default values, and can have all integer values up to the platform's capabilities. 

**Framework for setting for node allocation**

NODE_ALLOCATION_MODE

Description: This must adhere to the platform's capabilities, and describes the number of processes per node.

Allowed Values:

  • EXCLUSIVE: Allows only one task per node.
  • SHARED: Allows multiple tasks to share a node. [Default Value]

In thermal_chartran_cell_twoway.conf:

These will be shown with their default values, and allowed values are arbitrary strings unless otherwise stated.

Parameter Default Value Explanation

RUN_ID
case1
Indentifier for this simulation run CoupledCellElectroChemThermalTransport

SIM_NAME
${RUN_ID}
Name of current simulation, the default value automatically finds the name.

PLASMA_STATE_WORK_DIR
$SIM_ROOT/work/battery_state
Where to put state files as the simulation evolves, allowed values will be any existing directory.

RUN_COMMENT
Coupled CAEBAT Module simulation
A run comment picked up by the portal.

TAG
ElectroChemThermal
A tag that enables related runs to be retrieved together.

USER
ul2
An optional parameter, if missing the unix username is used.

NUM_ZONES, NUM_CHARTRAN_ZONES
15, 15
These are the number of zones for ---?

SIMULATION_MODE
NORMAL
The Simulation mode setting, with the allowed values of ---?

LOG_LEVEL
WARNING
This changes what will appear in the log, with the allowed values of ERROR or WARNING.

LOG_FILE
$SIM_ROOT/${SIM_NAME}.log
This determines the name and location of the created log file, and the allowed values are any path to an existing directory followed by ".log".

NAMES
INIT DRIVER CHARTRAN THERMAL
DRIVER and INIT are required values in the port section.

IMPLEMENTATION
CHARTRAN_THERMAL_DRIVER
This tells how the simulation initialized, and will generate the first state if needed.

For THERMAL,

IMPLEMENTATION = AMPERES.

For CHARTRAN,

IMPLEMENTATION = DUALFOIL.

These IMPLEMENTATIONs and DRIVERs are described below. 

**Individual configuration sections**

Component specification, with entries similar for all components. NAME entry must match the name of the python class that implements the component. This section is where the user can fine tune the simulation to their liking. The user can determine which scripts to execute, the input and output files, and the classes to run for these main three types of simulations.

CHARTRAN_THERMAL_DRIVER 

   CLASS = DRIVERS

This is a class from the initialized list in the PORTS section. 

   SUB_CLASS = CHARTRAN_THERMAL

This is an implementation for the above CLASS? 

   NAME = Driver

The name of the python class implementing the component. 

   NPROC = 1

This is the number of processes that can run at once? 

   BIN_PATH = $CAEBAT_ROOT/bin

This provides the location of the bin directory. 

   INPUT_DIR = $DATA_ROOT/

This provides the location of the input files. 

   INPUT_FILES =

This provides each required input file by giving their names. 

   OUTPUT_FILES = $CURRENT_STATE

This writes the output files to a certain file...? 

   SCRIPT = $BIN_PATH/thermal_chartran_driver_n.py

This tells which script to execute.

AMPERES 

   CLASS = THERMAL


   SUB_CLASS =


   NAME = Amperes


   NPROC = 1


   ELECTRICAL = 0


   BIN_PATH = $CAEBAT_ROOT/bin


   INPUT_DIR = $DATA_ROOT/amperes_thermal


   INPUT_FILES = 'Battery-zones1.e'


   OUTPUT_FILES = $CURRENT_STATE


   SCRIPT = $BIN_PATH/amperes_thermal.py

DUALFOIL 

   CLASS = CHARTRAN


   SUB_CLASS =


   NAME = DualFoil


   NPROC = 1


   BIN_PATH = $CAEBAT_ROOT/bin


   INPUT_DIR = $DATA_ROOT/dualfoil


   INPUT_FILES = 'dualfoil5.in' , 'li-ion-ebar.in'


   OUTPUT_FILES = 'df_caebat.out'


   SCRIPT = $BIN_PATH/dualfoil_chartran.py





**Time loop sepecification**

The two MODEs:

  • REGULAR: The framework uses the variables START, FINISH, and NSTEP.
  • EXPLICIT: The framework uses the variable VALUES (a space separated list of time values).

Below is shown the default values:

  • MODE = REGULAR
  • START = 0.0
  • FINISH = 30.
  • NSTEP = 1
  • VALUES = 3.4 3.5 3.6 3.7
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.