Creating additional experiment and device metadata templates #20
Conversation
* Because fields will be device specific, I believe we will need a different template for each device type. * I also created a 'general' template, for any device type not captured by existing templates.
* Added `device-type` as a field for all existing impedance metadata templates. * Populated `device-type` field for all impedance templates other than `impedance_general.yml`
Created impedance metadata templates for : * proton conducting ceramic fuel cell (pcfc) * alkaline exchange membrane fuel cell (aemfc)
Added `device-type` and `cycle-steps` fields, along with capability for mulitple cycle steps (CC, CV, pulsed, etc) to battery cycling metadata template.
`aemfc` and `pcfc` fields were incorrectly left as `pemfc` and `sofc`, respectively. These are now fixed.
Polarization metadata templates created for: * Alkaline Exchange Membrane Fuel Cells (aemfc) * Device not available among current template options (general) * Proton Conducting Ceramic Fuel Cell (pcfc) * Proton Exchange Membrane Fuel Cell (pemfc) * Solid Oxide Fuel Cell (sofc)
All other templates have the naming convention `experiment+device.yml`. Renaming battery cycling template to maintain consistency.
Previously, templates had the general structure of: * General descriptors * Bibliographic data * Most experimental details * Device details * Temperature details Separating the temperature details from the other experimental details in this manner was both arbitrary and accidental. I have moved the temperature fields in all templates so that they are adjacent to other experiment-related fields. Templates
|
@nicolet5 and @mdmurbach ... I propose adoption of these templates such that when a user specifies an exp_class of the above during upload, they are presented with a form containing these elements. I can take a stab at constructing the relational model in code and as an ER (not in that order, probably). |
|
FYI - some of these fields (min and max currents, etc) can be read directly from the data, so we don't need to bother the uploader and increase the barrier for entry. But they are still items we'll want to list in our table, allowing users to select data for download, which is why I included the fields in the template. |
|
The specific steps for sorting this out during upload require some though, imo. Something along the lines of:
Thoughts on items 3 and 5: my thought is there might be cost saving in holding off on some of this processing until we are sure that sufficient metadata will be provided. But I have no idea if that's true, or if it is simply easier to do all processing at once. Thoughts on 4a vs 4b. I think it might be simpler to just have GUI entry, at least at first. |
Populating metadata templates for a range of device and experiment types. Because the metadata fields vary widely with device type, I think device-specific templates are needed.
However, after writing all of these, the template is basically a concantenation of
header-info+experiment-info+device-info. FYI, I've got a branch that I'm working on so that we can just store one header for each experiment type, plus one header for each device type, and then auto-concatentate them upon request.