Replies: 12 comments 15 replies
-
Battery API
The bottleneck here is: would battery testing equipment have Open API specs (swagger.json)? Or this is something to be developed? Another challenge: battery scientists and devs. might find OpenAPI a bit complex and might need an abstraction layer. |
Beta Was this translation helpful? Give feedback.
-
|
@nickjtch Great overview of the tool. What are your thoughts about the battery-api in AmpLabs? Would you want to adopt it as written? Or would we different attributes and behaviors out of the box? I spoke with @tinosulzer yesterday about possible collaborations with PyBaMM and Galvanalyser team to support a common Battery API. That could be a good first collaboration project. |
Beta Was this translation helpful? Give feedback.
-
|
I think the existing battery-api is a great place to start. Just a few comments that I'll put here in the absence of a better place, could copy and paste to issues in the battery api github repo:
|
Beta Was this translation helpful? Give feedback.
-
|
@tinosulzer You're right. If user is treated as an author label then that makes sense to keep. As for authentication, if we can support OAuth in addition to bearer tokens I'd be happy from that perspective so we can plug it into our existing auth flow. As for Is
To your point about enforcement, I would think there are a certain subset of columns that satisfy a particular Standard. The API should support any format but we can bake in Governance & Compliance and someone should be able to decide on start what format they want to support. I am not a fan of returning a binary blob. One can work with it and display data for small datasets, but as the data gets larger we would need streaming capability. I like the Integrations
I went ahead and forked the battery-api repo if we can to coordinate & consolidate changes to propose against the main repo. In my experience these conversations work best when there is a concrete ask. A 'show me the code' conversation. https://github.com/amplabs-ai/battery-api |
Beta Was this translation helpful? Give feedback.
-
|
How would the Battery API and proposed structure mean for Beep? I imagine it's a matter of complying with the BeepDataPath, or treating the Battery API as a datasource type with a corresponding formatted example available in BEEP. i.e. if someone is talking to a service compliant with Battery API then beep would be able to read using a BatteryAPI(BeepDataPath) object. What do you think about this? @amalie-trewartha, @shijingsun-TRI |
Beta Was this translation helpful? Give feedback.
-
|
|
Beta Was this translation helpful? Give feedback.
-
GalvanalyserThe system contains the following main components:
The documentation is clear on how to deploy the Web App, creating users, etc. The architecture is neat. I guess there will plenty of room for collab. |
Beta Was this translation helpful? Give feedback.
-
|
@nickjtch Thanks for this breakdown as well. Similar to the Battery API, can we adopt components of Galvanalyser wholesale or what would we need to get started? |
Beta Was this translation helpful? Give feedback.
-
|
Direct areas of collaboration and discussion could be
|
Beta Was this translation helpful? Give feedback.
-
|
Galvanalyser Meeting Update
I think the harvester project seems the most interesting for our community and where we can provide value today. We can use the Tuesday meetings to discuss details around that work. |
Beta Was this translation helpful? Give feedback.
-
Main Categories
TODOs
|
Beta Was this translation helpful? Give feedback.
-
|
Link to Diagram: https://drive.google.com/file/d/1pNrOGnWpX44x_ofzwQAnwJmk0s3GLY3h/view?usp=share_link |
Beta Was this translation helpful? Give feedback.
-
|
03/07/23 Discussion
Conclusion
|
Beta Was this translation helpful? Give feedback.
-
|
03/14/2023
Next Steps:
|
Beta Was this translation helpful? Give feedback.
-
|
With my limited experience in battery testing or designign experiments, I inherently design a system that has limited constraint but can be flexible to support anything in the future. So I actually draw my inspiration from outside of Batteries. Here is an example of a yaml config that is used to define workflows in Jenkins. Jenkins snippetpipeline:
agent:
docker:
image: "node:12-alpine"
stages:
- stage: "Build"
steps:
- checkout: git@github.com:my-org/my-repo.git
- sh "npm install"
- sh "npm run build"
- stage: "Test"
steps:
- sh "npm run test"
- stage: "Deploy"
steps:
- sh "npm run deploy"And if we modify it slightly we can make it work for Batteries Battery Snippetpipeline:
environment:
charging: positive
vmax: 1000
precision: 1 (second)
stages:
- stage: Positive Current, Hold Voltage, Negative Current
steps:
- type: current
value: 5
unit: A
duration: 3600
- type: voltage
value: 10
unit: V
duration: 7200
- stage: Rest
steps:
- type: current
value: -5
unit: A
duration: 3600
- type: rest
duration: 3600What are all the possible keys? At the very least we will need tags for change tracking. Something like Example MetadataapiVersion: v1
metadata:
author: name
name: testname
description: a few words of context about this experiment that is useful to other people reviewing thisAll together a config could look Battery Example ConfigapiVersion: v1
metadata:
author: name
name: testname
description: a few words of context about this experiment that is useful to other people reviewing this
pipeline:
environment:
charging: positive
vmax: 1000
precision: 1 (second)
stages:
- stage: Positive Current, Hold Voltage, Negative Current
steps:
- type: current
value: 5
unit: A
duration: 3600
- type: voltage
value: 10
unit: V
duration: 7200
- stage: Rest
steps:
- type: current
value: -5
unit: A
duration: 3600
- type: rest
duration: 3600 |
Beta Was this translation helpful? Give feedback.
-
|
I like that this includes the sign convention for charging |
Beta Was this translation helpful? Give feedback.
-
|
What's are the pros/cons on infinite nesting? |
Beta Was this translation helpful? Give feedback.
-
|
@SamWilson22 On the surface, infinite nesting does make me nervous, my biggest concern is readability and learnability. If new developers want to build custom parsers or translate into other formats, it could be cumbersome to do. In general, I try to avoid infinite loops when possible but it is worth a discussion. @tinosulzer Do users typically want to define N-deep nested structures? Is that a common workflow for PyBaMM users? Should it be accepted as a requirement for the design? |
Beta Was this translation helpful? Give feedback.
-
Limitations
Final YAML# Example YAML file for a 1000-cycle 1C/1C CCCV cycling experiment for a 5 Ah cell with an RPT every 100 cycles
# Global parameters to take precedent over any cycling instructions
globals:
# Units
V_unit: V
C_unit: A
T_unit: C
duration_unit: seconds
# Configs
V_min: 2.5
V_max: 4.2
T_ambient: 25
T_max: 60
# list of instructions to follow sequentially
instructions:
# instructions composed from infinitely-nestable sequences
- sequence:
- sequence:
- type: current # current, voltage, power, duration, HPPC, CCCV, rest
value: 5 # A
time: 3600
- termination:
- type: voltage # current, voltage, power, duration, temperature
value: 2.5
name: optional
- type: current
value: 2.5
- type: duration
value: 2.5
- type: current
value: -5 # A
time: 3600
- termination:
- type: voltage
value: 4.2
- type: voltage
value: 4.2
time: 7200
- termination:
- type: current
value: 0.1
- type: rest
time: 3600
name: 1C/1C CCCV cycle
repeat: 100 # repeat this sequence 100 times before moving on to the next one
- sequence:
- type: current
value: 1 # A (C/5)
time: 3600
- termination:
- type: voltage
value: 2.5
- type: current
value: -1 # A (C/5)
time: 3600
- termination:
- type: voltage
value: 4.2
- type: voltage
value: 4.2
time: 7200
- termination:
- type: current
value: 0.1
name: C/5 RPT
repeat: 1 # or repeat defaults to 1 if not specified
repeat: 10 # repeat 100 cycles + 1 RPT 10 times |
Beta Was this translation helpful? Give feedback.
-
|
This is what I came up with: experiment.yamlconfig:
author: Sam
date: 03-14-2023
experimnet_name: cycling_1000_rp1_100_A1 # Up to user for naming/versioning scheme
ambient [C]: 25
duration [h]: 120
num_steps: 7
log Limits:
dv [V]: 0.001
dt [s]: 0.1
protection limits: # The experiment will automatically stop if these values are measured
vmin [V]: 2.49 #small buffer added
vmax [V]: 4.21 #small buffer added
cmin [A]: -5
cmax [A]: 5
tmin [C]: 0
tmax [C]: 60
steps:
- step_num: 1
step_type: CC Discharge
# You need all mandatory values to fully define the step. Will be different depending on the step type
mandatory values:
Current [A]: -5
#You need atleast one of these cutoff limit to fully define most steps. Will be different depending on the step type
cutoff limits:
Voltage [V]: 2.5
Time [s]: 3600
# Optional limits are additional. Ignore these for MVP
optional limits:
- step_num: 2
step_type: CCCV Charge
mandatory values:
Current [A]: 5
Voltage [V]: 4.2
cutoff limits:
Stop Cur. [A]: 0.1
Time [s]: 3600
optional limits:
- step_num: 3
step_type: Rest
mandatory values:
Time [s]: 3600
- step_num: 4
step_type: Cycle
mandatory values:
Step ID Reference: 1
Iterations: 100
- step_num: 5
step_type: CC Discharge
...
- step_num: 6
step_type: CCCV Charge
...
- step_num: 7
step_type: Cycle
mandatory values:
Step ID Reference: 1
Iterations: 10 |
Beta Was this translation helpful? Give feedback.
-
|
Here's another option, this one read directly from a google sheets table. YAMLdevice_id: DeviceID
duration: '259.03'
input_format: google_sheet
name: DeviceID_TestID
num_steps: 8
prot_limits:
cmax [A]: 10
cmin [A]: -10
tmax [C]: 60.0
tmin [C]: -40.0
vmax [V]: 4.21
vmin [V]: 2.49
steps:
- Capacity [Ah]: ''
Current [A]: ''
Increment: ''
Iterations: ''
Notes: ''
Power [W]: ''
Step ID: '1'
Step ID Reference: ''
Step Name: Rest
Step Time: '0:10:00.000'
Stop Cur. [A]: ''
Voltage [V]: ''
- Capacity [Ah]: ''
Current [A]: '5.0000'
Increment: ''
Iterations: ''
Notes: Cycling - Discharge
Power [W]: ''
Step ID: '2'
Step ID Reference: ''
Step Name: CC Discharge
Step Time: '1:00:00.000'
Stop Cur. [A]: ''
Voltage [V]: '2.50'
- Capacity [Ah]: ''
Current [A]: ''
Increment: ''
Iterations: ''
Notes: Cycling - Charge
Power [W]: ''
Step ID: '3'
Step ID Reference: ''
Step Name: CCCV Charge
Step Time: '4:00:00.000'
Stop Cur. [A]: '0.100'
Voltage [V]: '4.20'
- Capacity [Ah]: ''
Current [A]: ''
Increment: ''
Iterations: ''
Notes: Cycling - Rest
Power [W]: ''
Step ID: '4'
Step ID Reference: ''
Step Name: Rest
Step Time: '1:00:00.000'
Stop Cur. [A]: ''
Voltage [V]: ''
- Capacity [Ah]: ''
Current [A]: ''
Increment: '100'
Iterations: ''
Notes: ''
Power [W]: ''
Step ID: '5'
Step ID Reference: '1'
Step Name: Cycle
Step Time: ''
Stop Cur. [A]: ''
Voltage [V]: ''
- Capacity [Ah]: ''
Current [A]: '1.0000'
Increment: ''
Iterations: ''
Notes: RPT
Power [W]: ''
Step ID: '6'
Step ID Reference: ''
Step Name: CC Discharge
Step Time: '1:00:00.000'
Stop Cur. [A]: ''
Voltage [V]: '2.50'
- Capacity [Ah]: ''
Current [A]: '1.0000'
Increment: ''
Iterations: ''
Notes: RPT
Power [W]: ''
Step ID: '7'
Step ID Reference: ''
Step Name: CCCV Charge
Step Time: '4:00:00.000'
Stop Cur. [A]: '0.100'
Voltage [V]: ''
- Capacity [Ah]: ''
Current [A]: ''
Increment: '10'
Iterations: ''
Notes: ''
Power [W]: ''
Step ID: '8'
Step ID Reference: '1'
Step Name: Cycle
Step Time: ''
Stop Cur. [A]: ''
Voltage [V]: ''
- Capacity [Ah]: ''
Current [A]: ''
Increment: ''
Iterations: ''
Notes: ''
Power [W]: ''
Step ID: '9'
Step ID Reference: ''
Step Name: End
Step Time: ''
Stop Cur. [A]: ''
Voltage [V]: ''Table
|
Beta Was this translation helpful? Give feedback.
-
White paper by ChatGPTTitle: Standard YAML Configuration File for Battery Testing Equipment Introduction:Battery testing is a critical step in the development and production of batteries. It involves subjecting batteries to a series of tests to assess their performance, reliability, and safety. To ensure consistent and accurate testing results, battery test engineers need to configure their testing equipment correctly. In this white paper, we will introduce a standard YAML configuration file that battery test engineers can use to configure their battery testing equipment. Background:Currently, there is no standard configuration file format for battery testing equipment. Different equipment manufacturers use different file formats, making it difficult for battery test engineers to switch between equipment or to collaborate on testing projects. To address this problem, we propose a YAML configuration file format that can be used across different equipment manufacturers and testing environments. The YAML Configuration File:The YAML configuration file consists of two main sections: the global parameters and the list of instructions. The global parameters define the units and configurations that apply to all instructions. The list of instructions is a sequentially executed set of commands that define the battery testing experiment. Global Parameters:The global parameters section contains a set of predefined variables that apply to all instructions. The variables include: V_unit: The unit of measurement for voltage. List of Instructions:The list of instructions is a sequentially executed set of commands that define the battery testing experiment. The instructions can be infinitely nested within sequences, allowing for complex and sophisticated test procedures. Each instruction has a type, a value, and an optional termination condition. The types of instructions include: Current: Applies a constant current to the battery for a specified duration. Termination Conditions:Each instruction can have an optional termination condition, which is a set of criteria that must be met before the instruction can be terminated. The termination conditions include: Voltage: The battery voltage must reach a specified value. Conclusion:The standard YAML configuration file proposed in this white paper provides a common language for battery test engineers to configure their battery testing equipment. By using a standard format, battery test engineers can switch between equipment manufacturers and collaborate on testing projects more efficiently. The YAML configuration file is flexible and customizable, allowing for complex and sophisticated test procedures. We believe that this configuration file will improve the consistency and accuracy of battery testing results, ultimately leading to better battery performance, reliability, and safety. |
Beta Was this translation helpful? Give feedback.
-
Codeclass GlobalParams:
def __init__(self, V_unit, C_unit, T_unit, duration_unit, V_min, V_max, T_ambient, T_max):
self.V_unit = V_unit
self.C_unit = C_unit
self.T_unit = T_unit
self.duration_unit = duration_unit
self.V_min = V_min
self.V_max = V_max
self.T_ambient = T_ambient
self.T_max = T_max
class TerminationCondition:
def __init__(self, type, value, name=None):
self.type = type
self.value = value
self.name = name
class Instruction:
def __init__(self, type, value, time, termination=None, name=None, repeat=1):
self.type = type
self.value = value
self.time = time
self.termination = termination
self.name = name
self.repeat = repeat
class Sequence:
def __init__(self, sequence, name=None, repeat=1):
self.sequence = sequence
self.name = name
self.repeat = repeat
class CyclerConfig:
def __init__(self, globals, instructions):
self.globals = globals
self.instructions = instructionsWith these classes defined, we can create an instance of the YAMLConfig class as follows: # Create global parameters object
globals = GlobalParams(V_unit='V', C_unit='A', T_unit='C', duration_unit='seconds', V_min=2.5, V_max=4.2, T_ambient=25, T_max=60)
# Create instruction objects
instruction1 = Instruction(type='current', value=5, time=3600, termination=[TerminationCondition(type='voltage', value=2.5, name='optional'), TerminationCondition(type='current', value=2.5), TerminationCondition(type='duration', value=2.5)])
instruction2 = Instruction(type='current', value=-5, time=3600, termination=[TerminationCondition(type='voltage', value=4.2)])
instruction3 = Instruction(type='voltage', value=4.2, time=7200, termination=[TerminationCondition(type='current', value=0.1)])
instruction4 = Instruction(type='rest', time=3600)
instruction5 = Instruction(type='current', value=1, time=3600, termination=[TerminationCondition(type='voltage', value=2.5)])
instruction6 = Instruction(type='current', value=-1, time=3600, termination=[TerminationCondition(type='voltage', value=4.2)])
instruction7 = Instruction(type='voltage', value=4.2, time=7200, termination=[TerminationCondition(type='current', value=0.1)])
sequence1 = Sequence(sequence=[instruction1, instruction2, instruction3, instruction4], name='1C/1C CCCV cycle', repeat=100)
sequence2 = Sequence(sequence=[instruction5, instruction6, instruction7], name='C/5 RPT')
instruction_list = [sequence1, sequence2]
instruction8 = Sequence(sequence=instruction_list, repeat=10)
# Create CyclerConfigobject
config = CyclerConfig(globals=globals, instructions=[instruction8])In this example, we create instances of each class and then combine them to create an instance of the YAMLConfig class. This config object can then be written to a YAML file using the yaml.dump() function |
Beta Was this translation helpful? Give feedback.
-
|
Hey, sorry I can no longer make the Tuesday meetings. I have started a refactoring pybamm to create a |
Beta Was this translation helpful? Give feedback.
-
|
Hi everyone, we're having discussions with more members of Dave Howey's group about this. Not sure whether it's still active on the Amplabs side but PyBaMM now supports a new instruction step and the experiment class can also take tuples of instructions like the sequence you have defined above. Did you implement the YAMLConfig class? If so we can work on accepting that directly without too much effort I think. |
Beta Was this translation helpful? Give feedback.
-
There is an existing integration between the APIs that allow Galvanalyser data to be published to AmpLabs, we can use this space to discuss additions to that or new ideas as well.
https://github.com/Battery-Intelligence-Lab/galvanalyser
https://github.com/martinjrobins/battery-api
Beta Was this translation helpful? Give feedback.
All reactions