{"id":24543,"date":"2022-01-01T15:59:52","date_gmt":"2022-01-01T15:59:52","guid":{"rendered":"https:\/\/www.ch.imperial.ac.uk\/rzepa\/blog\/?p=24543"},"modified":"2022-01-11T07:33:00","modified_gmt":"2022-01-11T07:33:00","slug":"quantum-chemistry-interoperability-library-another-step-towards-fair-data","status":"publish","type":"post","link":"https:\/\/www.ch.ic.ac.uk\/rzepa\/blog\/?p=24543","title":{"rendered":"Quantum chemistry interoperability (library): another step towards FAIR data."},"content":{"rendered":"
\n

To be FAIR, data has to be not only Findable and Accessible, but straightforwardly Interoperable. One of the best examples of interoperability in chemistry comes from the domain of quantum chemistry. This strives to describe a molecule by its electron density distribution, from which many interesting properties can then be computed. The process is split into two parts:<\/p>\n

    \n
  1. Computation of the wavefunction. This can be very very compute intensive process, which can take quite a few days even using 64 or more processors in parallel and requires highly specialised programs to achieve this.<\/li>\n
  2. Analysis of the wavefunction. The range of properties that can be computed is impressively large, but again this requires specialised algorithms and programs.<\/li>\n<\/ol>\n

    So one can see that the need to Interoperate wavefunction data computed during process 1 into analysis in process 2 is crucial. This is normally achieved using intermediate data files, and clearly the semantics of the data in these files must be perfectly communicated between the two processes.<\/p>\n

    With this introduction over, my attention was drawn to a recent post on the CCL (Computational Chemistry List,\u00a0http:\/\/www.ccl.net<\/a>), a veritable resource that has been running for many decades and where many aspects of computational chemistry are discussed. One recent such relates to quantum chemistry interoperability; http:\/\/www.ccl.net\/cgi-bin\/ccl\/day-index.cgi?2021+12+30<\/a> where many interesting points were made. I highlight just two here (but urge you to read the entire thread).<\/p>\n

      \n
    1. The first, by Mike Frisch (http:\/\/www.ccl.net\/cgi-bin\/ccl\/message-new?2021+12+30+003<\/a>) introduces two interoperability formats (the binary array file<\/strong> format) along with a library of routines in both Fortran and Python which facilitate interoperability between wavefunction calculating and the post-processing analysis programs. The advantages of this include “Like the fchk file, this is a\u00a0self-defining file, but it is binary so that full precision can be retained\u00a0and reading\/writing the file is much faster<\/em>” and is described at https:\/\/gaussian.com\/interfacing\/<\/a> Output in this format is controlled by the keyword Output=MatrixElement<\/strong> or use of environment variables. As a long time user of an older interoperability mechanism, the so-called WFN<\/strong> and WFX<\/strong> formats for use with programs such as AIMALL and MultiWFN, I have often set this keyword to eg Output=wfn<\/strong> and when generated, such files are routinely included in our FAIR data publications which are often mentioned both in this blog and in the journal articles we write. If you read the post by Mike, you will understand both the deficiencies of these earlier formats and how the binary array file is an important advance.\u00a0\n