[cclib-devel] MolSSI + CJSON and cclib

[Eric B. <er...@pi...>]

Hi everyone,

I've been invited to attend the a MolSSI workshop on quantum chemistry
schema at LBNL on 11/30 and 12/1; I've attached a PDF of the solicitation.
Here is Daniel Smith's email to me:


> During a MolSSI Interoperability Workshop this year, one topic that came
> up was an interoperable schema between various quantum chemistry programs
> so that users and developers could have a unified interface to move data in
> and out of these very large programs as opposed to processing ASCII files
> and building custom inputs. To this end, we have been tweaking a base
> schema and talking to the creators of the many different schema already out
> there in the hope of unifying these diverse groups. We hope to pull in
> approximately 30 quantum chemistry developers from a broad set of
> backgrounds and programs to make this a reality.
>
> The current version and primary discussion of the schema can be found on
> GitHub here: https://github.com/MolSSI/QC_JSON_Schema
>
> We would encourage your entire community to discuss the schema in its
> current form in order to spur more discussion and tune the overall scope of
> the schema on the GitHub page, otherwise feel free to email me back
> personally if you have any questions. For the workshop participant, we are
> looking for one developer that would represent your community to help
> finalize the schema and decide on future governance and communication plans.
>

As of right now, I am not representing cclib since we should come to some
census decision about our path. I do feel it gives us more exposure, which
is good, and would push development a bit, which could be a pro or a con.
We are well-positioned to implement (now or soon) all of their requirements
(https://github.com/MolSSI/QC_JSON_Schema/blob/master/Requirements.md),
especially for QM packages that will certainly not support the schema
directly. A substantial amount of work was already done by Sanjeed during
GSoC last year as part of CJSON, which itself is being unified. Our
transition to more modular attributes, which we've already started
discussing, can only make this easier.

Their repository is just a few Markdown files and is worth reading. As far
as what our obligation would be, I think it would be to implement their
spec, with their development assistance if need be. Implicit in my
invitation to the workshop is that I'd do most of the heavy lifting. In
particular, since large data (MO coefficients, densities, response vectors,
...) will need to be stored, we will probably need an HDF5 interface that
can be optional, similar to how our other bridges are already optional. One
question is whether or not there will be a fallback non-binary
representation for these fields.

Please let me know your thoughts/questions/suggestions/concerns.

Eric