Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

loss of <I> column in the converted json from the mpr file in GCPL technique using yadg 4 #122

Closed
NukP opened this issue Sep 28, 2023 · 5 comments
Labels
wontfix This will not be worked on

Comments

@NukP
Copy link

NukP commented Sep 28, 2023

Background
When using yadg 4 to convert mpr file to json file, serveral data columns went missing although these columns are present in the mpt file generated from Biologic. Unfortunately, these missing data column, <I>/mA, in particular is crucial for plotting the data from GCPL experiment. The user has requested that this column is included in the json file.

Investigation done so far

  • I have suspected that the issue may have come from the eclabmpr parser. In particular, this parser uses _parse_columns function to read the column header in the mpr files before reading them and compile them into a datapoint which is subsequently written into a json file. I have tried to print the names, dtypes, units, flags which is returned from the _parse_columns and found that the headers matches what is found in the json file. Strangely, the name stored in the names parameters only cover parts of the data column in the resulting mpt file. In particular, only from mode to Capacitance discharge/µF column.
  • I have tried to modify the script (I folked the project and run in a separate conda environment), and manually add names, dtypes, units for <I> so that the script will extract this column from the mpr file. But, I got an error about not enough numpy buffer. I tried to add the attibute that I am sure not in the mpr file (by mispelling the name) and got a similar error. This led to my conclusion that the <I> column may not exits in the mpr file in the first place and the yadg was performing correctly.

My suspision so far

  • From the investigation I have done earlier, I now think that Biologic may have derive and generate the data from <I>/mA to cycle number (in the mpt file) during mpr to mpt conversion. These data columns may not have present in the original mpr file.
  • <I>/mA, for example, can be derived from dq/mA.h. Nevertheless, I have not yet verified this speculation with the user whoes have experince with battery electrochemistry.
  • This speculation is in line with the issue reported earlier (Check differences in mpr files before & after opening in EC-Lab. #41) that there will be more column stored in the mpr file after the user perform the conversion to mpt.

Corresponding files
https://drive.switch.ch/index.php/s/AGzUx3wPHscdWnq

@PeterKraus
Copy link
Contributor

Thanks for bringing this issue up to github. Maybe @vetschn can chime in.

I seem to recall that <I> might be an optional column for some techniques, at least remembering there was an option somewhere in the EC-Lab interface. However, it seems strange that a current would not get recorded during the run at all.

Unfortunately, the headers from the mpt file have been stripped. Could you please re-export the mpt file so that the header (describing the technique "steps") is retained? I had a look in the mps file, and the only 15-minute interval seems to be Ns 1 of Technique 1, but I guess the cycling data are from Ns 3 and 4 in Technique 2.

As a measure of last resort, the <I> can be generated from the dq data and timestamps; it is simply <I> = dq / dt. I think the current implementation in dgpost expects the total Q, not dq, but this should be a simple fix.

@PeterKraus
Copy link
Contributor

I have attached a plot illustrating the issue, this was generated using yadg-5.0a5 from the above mpr file:
plot
Here, red is Ewe, green is control_I, blue is (Q-Qo) and orange is Ns.

We can see that the spike in control_I conicides with Ewe reaching its limit value, which happens in the last few minutes of each step (i.e. before Ns change, not after).

This means:

  • control_I is not really control_I at all the times. The "limiting property" during constant current steps in GCPL may not be current but voltage, if applying the full requested current would break the voltage limit I imagine.
  • we can use (Q-Qo) as Q in the dgpost.transform.electrochemistry.average_current() function to get <I> that way.

@vetschn
Copy link
Contributor

vetschn commented Oct 2, 2023

Yep, I think @NukP's initial suspicion is completely correct, the mpr file does not contain the <I> column.

From the "variables description" section in the EC-Lab User's Manual:

<I>, average current over the potential step (calculated from I = dQ/dt)

so the dgpost.transform.electrochemistry.average_current() function is the way to go 👍

@NukP
Copy link
Author

NukP commented Oct 2, 2023

@PeterKraus Here is the mpt file with the header. https://drive.switch.ch/index.php/s/Mc0XZCDeOK3BkLl

So does this mean that during the mpr to json conversion, I should first call yadg to do the conversion and then use dgpost to convert Q-Qo to <I> ?

@PeterKraus
Copy link
Contributor

Well, yadg is not meant to do any postprocessing, so any output file (json in v4 and netcdf in v5) will not have <I> in them, if it's not in the "source" files.

You will have to calculate the current somehow in a postprocessing step. The dgpost function is just a convenient way to do it...

@PeterKraus PeterKraus added the wontfix This will not be worked on label Oct 3, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
wontfix This will not be worked on
Projects
None yet
Development

No branches or pull requests

3 participants