为什么计算化学软件喜欢用二进制文件存储波函数？

Freeman

为什么计算化学软件喜欢用二进制文件而非文本文件存储波函数呢？
一般来说，波函数的必要信息就是分子几何坐标、基组信息和轨道系数矩阵，完全可以用文本文件存储。高斯支持的chk（二进制）和fchk（文本），orca支持的gbw（二进制）和molden（文本），都可以互相转换，说明二进制和文本内的信息都是相通的。
使用文本文件存储波函数还有几个好处：1、占用空间小（fchk大小一般只有chk的一半）；2、方便阅读和修改；3、方便转换格式，把软件A算出来的波函数喂给软件B当初猜；4、不用担心在平台A产生的波函数文件，丢给平台B就打不开。
但是好像所有软件都喜欢用二进制文件存储波函数，而且就我所知只有高斯和orca支持把自己的二进制波函数文件转换成文本文件。为什么呢？

niobium

zjxitcc 发表于 2022-8-11 10:59
fch一般比chk文件小。现在有时（或者说经常）会出现fch文件比chk文件大，是因为fch末尾有大量无用信息， ...

主要原因是二楼子宽大神说的，表示同一个数，文本要比二进制大很多，所以即使fchk里面的信息少于chk，也会在体系大到一定程度后，fchk大于chk，这之间有个交叉点。

zjxitcc

niobium 发表于 2022-8-11 08:28
fchk比chk小，只能说明你做的计算太少或者太小

fch一般比chk文件小。现在有时（或者说经常）会出现fch文件比chk文件大，是因为fch末尾有大量无用信息，在Total SCF Density之后的所有内容，其实可以删掉。另外，从G16C开始，若做CIS/TDDFT计算，formchk会把组态系数写进fch文件，导致大体系的fch文件巨大无比。

niobium

fchk比chk小，只能说明你做的计算太少或者太小

sobereva

chk用formchk转成fchk后存的信息量远比chk要少。若再用unfchk转回chk，就会发现小于chk。
绝大多数量化程序总能以至少一种方式给出文本形式记录的波函数信息，比如Dalton、Molpro、xtb、CP2K等都能给出文本形式的molden文件，GAMESS-US在默认的NPRINT参数下得到的输出文件里也有充分的轨道信息。
但各种量化程序之间缺乏统一、严格、理想的文本格式交互波函数信息是个问题，所以我之前提出了mwfn格式（https://doi.org/10.26434/chemrxiv-2021-lt04f-v6）

lyj714

另外，二进制文件读写速度要比普通文本文件读写快很多的，特别是数据量非常大的情况。直接操作二进制流比什么一行一行的读写文本快，这是毋庸置疑的。

hebrewsnabla

关于3，首先一个程序最初开发的时候一般是优先考虑自己读写方不方便的，不会太考虑和别的程序交互。
其实转换或读取二进制文件往往不是传轨道的主要障碍，大部分程序的二进制要么很好读（例如qchem，以及使用hdf5的一众程序）要么提供转换工具，当然死活不提供的也有。
主要障碍还是由于各个程序的积分库和某些convention不一样，得解决基函数顺序，是否归一化，是否差个常数，是否差个符号等等各种问题…… 还有就是传过去如何检验传对了，需要对两个程序的细节有一定了解。关于2，
文本格式固然方便肉眼阅读，但是如果考虑到程序“阅读”进行后处理的话，二进制也很方便（只要二进制格式是公开的（或者不公开，只方便内部开发者。

关于4，比较现代的二进制文件是可以跨平台的，如hdf5。

zjxitcc

二进制文件确实多，但文本文件也不少，MOKIT就是瞄准了那些有轨道文本文件的量化程序。。。比如OpenMolcas的INPORB, ScfOrb等，Molpro的xml，GAMESS的dat文件。一般来说，多少总是支持一种文本格式的。

wzkchem5

fchk比chk小应该是因为fchk存储的信息比chk少，以及很多数存储的精度比较低吧？
二进制文件存储浮点数的效率大概是文本文件的2倍多，一个双精度数用二进制文件存储需要8字节，用文本文件基本需要20字节才能保证不丢失精度（16位有效数字，加上小数点、科学计数法的指数，以及分隔各个数的空格）。实际上二进制文件的主要优势就是同等精度下文件比较小，如果不考虑这一点，基本没有什么理由用二进制文件。