Skip to content
David Hurt edited this page Feb 6, 2020 · 4 revisions

Project Codename: "EISy as Py"


Project-Planning Markdown (WIKI-TO-BE)

Created 2020-02-04, by D.Hurt following our first ever Group Planning Meeting and the class period where our mighty overlord DaveBeck laid out the Rules, Regulations, Rubrics, and Rythmatic of the project.


ABSTRACT:

(1-Minute Project Pitch) The overall goal is to have a python package that can facilitate high quality data manipulation in regards to EIS battery experiments. Open source tools exist already to process some EIS information which we will study and build from, but we're specifically looking to add the following utilities which aren't out there to our understanding:

  • "Scan Quality Determination" - Given a test scan, there are many things that can go wrong and we want to be able to Identify a 'failed' or 'error' test, which may have to be re-ran.
  • "Recognize EIS features and generate standard visualizations"
  • "Database Setup/Output" based on a users' needs/experiment metadata, and storing output data there

Table of Contents:

  1. Abstract
  2. Team
  3. Data
  4. Scope
  5. Project Status

TEAM:

Maria Politi:

  • Affiliated Labs/Projects: Adler + Pozzo Groups:
    • Redox Flow Battery R&D
    • Long-term Research Goal is High-Throughput experiments to ID new electrolytes(?) to use in next-gen (first gen? haha) Redox Flow Batteries.
    • Personal Research Project(s): Setting up Database collection methods, to be used to quickly Upload/Preprocess/store info for these "High Throughput Experiments", to be Mined later and discover results!

David Hurt:

  • Affiliated Labs/Projects: BenAn Battery Technologies:
    • Aqueous Stationary Battery R&D
    • Using Nontoxic, Cheap and Abundant materials for low-density energy storage (primarily for solar/wind installation projects, and for backup grid support in the developing world)
    • Personal Research Project(s): Cycling data processing, Setup of Quality Control testing, currently Jack-of-all-trades for dev/testing new prototype.

Yao-Yu (Joe) Li:

Abdul Moeez:

  • Affiliated Labs/Projects: Jun Liu Lab:
    • Sodium-Ion Cathode Development!
    • Lab-Relationships at PNNL, Battery500 Consortium

Mihyun Kim:

  • Affiliated Labs/Projects: Dan Schwartz Lab:
    • He essentially owns the WCET!
    • Lots of fun EChemE Things going on

DATA SETS:

Equipment from Our Lab/Professor Friends!

We plan to use a variety of EIS data sets from a variety of testing equipment, which we can list here:

  • "BioLogic" Testers: High quality, Expensive machines which will export highly processed data and results, but can PROBABLY also output raw data files. We should be able (Ideally) to accept any format...
  • Homebrew PhD Student Systems!: The most FUNDAMENTAL EIS data format, can be acheived using a frequency generator/Oscilliscope! You'll maybe only have Voltage, Current, and Time collumns, but with that you should be able to FFT your waveforms, and generate All the data you need! Thus your \$100 machine can do everything a \$10,000 Biologic can!
  • WhattevaDaFuq We have at the WCET?:

We would like to have the code process a wide variety of EIS results, so it would be great to get EIS data from as many different sources (and types of batteries/circuits) as possible! Options:

  • Adler Lab (Maria): They initiated the project, but we don't know how much data they already have for us to use and work with. As of our meeting on 2020-05-02 they don't have data for us, BUT they have equipment will be useful in making sure our importers work for their exported data types.
  • BenAn Batteries (David): We're a private company? They may or may not be okay with us publishing our data. HOWEVER my boss Tom is a cool guy (as are my coworkers in Shanghai) so I think as long as we can be sure that we're not publishing that EIS data, we can probably use it to help and train the model. ESPECIALLY since it will be open source and my coworkers can use it if it's good, so we would love to know that it works for our cells!
  • Schwartz Lab (Mihyun): Again. They own the WCET. I bet they have lots of very different EIS stuff they can share.

GENERATED "Model" EIS DataSets, from Existing Python:

The Impedance.py tools were developed here at UW, by students during a hackathon! We plan to meet up with that group soon, to talk about their learnings and see if they have a "Wish-List" of things that their code doesn't do, so we aren't wasting time overlapping too much with work they've already done. Open source at its best!

One thing we know that their code can do, is that given an "Equivalent Circuit" Imput (aka: Series of Theoretical-Resistors/Theoretical-Capacitors/Theoretical-Inductors), it can generate "MODEL" EIS data! While obviously that is theoretical data and won't work for data mining real-world datasets (THERES NO METADATA, Duh!), it should be perfect for training our model to do "Pre-Processing". We haven't played with it yet - Maybe it can generate really complex model data that can actually empirically fit some REAL world data! That'd be awesome!

Publically Available EIS Data:

I honestly don't know where I'd find publically ready EIS data to use, but it might be out there! We should call the Modelling teams at Argonne national labs (and others), but Argonne makes the BATT-PAC model, which is fantastic for people who are trying to play with high level battery stuff.

ADDITIONAL NOTE on DATA:

We need to figure out where we will store the datasets we accumulate. This discussion was had in class and mostly comes down to using a Google Drive server. (Perhaps a new Google Drive for the group, so it can be shared easily, or else simply one that we Give Public Read Access)


SCOPE and PROJECT OUTLINE:

In a General Order of priority, here is a list of Functionality that the project should have:

  1. EIS Data Import: We want to take in EIS data, in (ROUGHLY) any format that our testers spit it out, and Process it into the most common format of datasets.

  2. Common EIS Data Processing: There is a lot of very well standardized ways that EIS data is processed, compared, etc. Do that.

    • FFT analysis to get Frequency/Z/R data
    • Equivalent Circuit Diagram / Values (That's harder than it looks like, but is also so standard that I think the existing tools already might do it)
  3. Common EIS Data Visualization: Similarly, there are many standard data visualizations for people who do EIS work. Spit those out, nicely organized, for us!

    • Nyquist Plot: "Real R" vs "-Imagnary Z"
    • Bode Plot: X-Axis is FREQUENCY (via FFT), Y axis are MAGNITUDE (mA) and PHASE-SHIFT($\theta$)
  4. Meta-Data Import: In order to do any sort of Machine learning, Users need to be able to submit any/all relevant MetaData that they want. We should be prepared for MANY types of metadata, but should also allow users to Custom-Input the Data that matters to them! At the very least, this data should be saved with the analysis of each EIS results so it can be further used

  5. DATABASE Setup (Optional? SQL??): I'm out of my depth here, but I think we can input/ouptut some of these results as SQL or other database-style results! If so, we could have this python package include functions that will Setup, Update, and Query a database of our users' Design!

  • LOTS OF OTHER THINGS!!!! There's so much that we could do, we need to talk and figure out what is the best priority and what sort of scope could we get done in the semester that remains to us. This might be it, or we might do a lot more!

RESEARCH:

This section (Near the end? Up at the top?) will serve as a Link and Summary repository, for all of the many many things that we all are doing to research EIS, Existing tools, and anything else relevant to our project!


STATUS, BUGS, and TIMELINE:

Again, list of things that we are actively working on. When the work is underway this might be the Backlog/TO-DO section, and we'll turn the SCOPE/GOALS section into the SUCCESS-STATUS section that accumulates the parts that actually work!