Before I submit a PR:

There is inconsistent usage of _adsorp_amount and _adsorp_loading in the repo. (Same for _desorp.) The manuscript defines _adsorp_amount as the "amount adsorbed," but _adsorp_loading appears in both examples and processing scripts. Is it OK to switch everything to _adsorp_amount?

Tests leave X.aif and X.pdf files behind, add a step in the tests hook to clean up.

During a conversation with an instrument manufacturer, it was suggested that AIF have functionality to enable 'signing' the isotherm, to facilitate an integrity check mechanism A quickly thought up option is to develop a hashing algorithm for the AIF file, then include the hash in the AIF dictionary itself.

The big issue is how to protect and distribute the key(s) used for the signing function. It's easier to accomplish this in proprietary software!

Caveat: I do not know much about how to create a secure workflow for signing and validation.

When uploading a Micromeritics XLS file with the temperature units set to degree Celsius, the web interface shows the correct Celsius temperature value, as Kelvin.

Is there a way to have the web interface have the option to either directly display the Celsius temperature, or automatically convert it to Kelvin?

I've written some simple AIF2JSON and JSON2AIF convertors, located in https://github.com/dwsideriusNIST/adsorptioninformationformat/tree/sandbox

This is intended to be a discussion starter. Writing the converters revealed the need for kludges due to differences in approach between AIF and NIST-JSON; this will be informative for developing uniform standards.

Let me begin first by thanking you (@jackevansadl and team) for coming up with such a valuable tool for the adsorption community - I think it'll be really helpful 👍

I was wondering if it would a good idea to have data tags particularly for simulation data, along the lines of something like:

_simln_operator
_simln_software
_simln_adsorptive
_simln_temperature

Happy to work on an implementation for this if everyone agrees - Thanks! ☺️

As the title says, I propose to have a separate package on pypi that would act as a collection of python parsers.

Background

I am also maintaining a collection of parsers in pyGAPS. I have recently added a few tweaks for better parsing of Micromeritics files and for reading of reports from 3P instruments. It would be ideal if I could contribute these to the parsing used by the AIF. It would also be good if I could benefit from changes in this repo (like the recent JIS tweaks). However, I find it is difficult as the codebases have diverged, it takes a lot of time to compare and correctly integrate changes from one to another.

Proposition

Common parsing code can be placed in a separate repo, under AIF-dev-team. This would then be published to pypy as an independent package, for ex adsorption-file-parsers. Anyone wishing to use them in their projects could then install and depend on this package, allowing for a single source of truth. Any improvements could also be contributed directly here and propagate seamlessly.

Would be open to maintaining the package.

Implementation

For each type of file, a module would be created in the parsing package. The module would have a main function that deals with files of the correct type, perhaps with other options.

from adsorption_file_parsers import parse_micromeritics_rep

file_data = parse_micromeritics_rep("path/to/file", *options)

Challenges

• Should depend on least number of external packages.
• A common return type should be agreed upon, ideally pure Python, e.g.:

data = {
    "metadata": {}, # dict
    "pointdata": {}, # dataframe? dict? lists?
}

Windows executable to be created for "raw2aif_gui.py"

When clicking on the download link for my generated .AIF file, it downloads as expected, but the file format is .AIFF rather than .AIF. This persists across re-uploads of the file, refreshes of the page, and trying to right-click>'save link as'. After opening the file in Notepad++, all the information is there, simply the extension is wrong.

This happens on Firefox 117.0.1, with a Micromeritics XLS file.

Hi! currently, pyGAPS can't parse the latest version of aif unfortunately, e.g.

from the recent paper from the Petit group - I've attached their aif isotherms for convenience.
I know the parser in pyGAPS will eventually be updated to fix this (by me if I get the time), but is it possible to simply convert the isotherms to a previous version, e.g. 6acf6ef?
Will contact the authors anyway, but just checking if there was a simple solution within aif (without me manually going through all the files!)
je3c00504_si_002.zip

Care of @dwsideriusNIST

High-priority followup work include: suppressions of duplicative-code (primarily for the BEL parsers), use-a-generator, no-else-returns, no-else-continue.

Lower priority: too-many-locals, too-many-branches, too-many-statements [some of these cannot be avoided, but let's at least try]

Wondering if it would be possible to add a feature whereby you could simply copy and paste the adsorption data (say from CSV) on the GUI? If data is not in one of the supported formats, the parser doesn't work.

Obviously this can be done by manipulating an aif file itself, but may improve workflows if it could be done in the GUI.