B10. How come binary blip wave function files (bwfn.data.bin or b1) produced in different ways for the same system have very different files sizes?

The authors of the various interfaces between CASINO and plane-wave codes such as PWSCF/CASTEP/ABINIT make different assumptions about which unoccupied orbitals should be included in the file.

For example, with CASTEP/ABINIT you always have to produce a formatted pwfn.data files as a first step, then this must be transformed into a formatted blip bwfn.data file using the blip utility, then when this is read in by CASINO, this will be transformed into a much smaller bwfn.data.bin file (if keyword write_binary_blips is T, which is the default.

With PWSCF, you may produce any of these files (pwfn.data, bwfn.data or old format bwfn.data.b1) directly with the DFT code without passing through a sequence of intermediaries.

In the CASTEP case, the unstated assumption is that the formatted file is kept as a reference (either pwfn.data or the larger bwfn.data depending on whether disk space is a problem) and that this contains all the orbitals written out by the DFT code. When converting to binary, only the orbitals occupied in the requested state are written out. If later, you want to do a different excited state, then the bwfn.data.bin file should be regenerated for that state.

In the PWSCF case, because the formatted file need never exist, then all orbitals written by the DFT code are included in the binary blip file (old format bwfn.data.b1) including all unoccupied ones. Thus these files can be considerably larger than ones produced through the ABINIT/CASTEP/blip utility/CASINO route.

In general one should control the number of unoccupied orbitals in the blip file through some parameter in the DFT code itself. For example, you might try the following:

CASTEP : Increase ‘nextra_bands‘ to something positive.
Note that CASTEP has a help system just like CASINO’s casinohelp.
Type ‘castep -help nextra_bands‘.

Note that it is planned to tidy this system considerably in a future release of CASINO (including making the blip utility write in binary directly from the pwfn.data, without bwfn.data ever having existed).