c2x limits and bugs

C2x is not perfect, and here are listed some of its more major imperfections.

32 bit issues

C2x uses 32 bit ints rather more than it ought. This leads to overflow problems with large datasets.

Versions up to and including 2.40c

In versions prior to 2.40c, issues are likely to be encountered if the charge density is larger than 2GB, or, in some cases, larger than 2GB when stored as double precision complex. In other words, it is safest if the product of the FFT grid dimensions is less than 2²⁷, so a grid of 512x512x512 may be too large, and the largest cube with sensible factors which is fine is 500x500x500.

This is much larger than any calculation I have ever done, but it is might be an issue for some.

In the case of VASP output, WAVECAR files of more than about 2GB might also prove to be unreadable.

Versions 2.40d and subsequent

Verion 2.40d benefits from some minor improvements in this area. The limit on a charge density is believed to be 2³¹ elements, and the limit on the size of VASP WAVECAR files has effectively been removed, provided that sizeof(long) is 64 in both cases, which it will be on Linux and MacOS, and probably is not on Windows.

There remains a limit on the size of an array on which c2x can perform a 3D FFT of about 2³⁰ elements.

It would be possible to remove most of these limits, but I am unaware of demand. A grid size of over 1000x1000x1000 is really pretty large for a DFT calculation.

I/O performance

Versions up to and including 2.40c assumed that calls to fseek() were effectively free. This is not so; in many cases fseek() implies fread(). Version 2.40d reduces its use of fseek() when reading wavefunctions from Abinit, Castep and Quantum Espresso. In some cases it can process files over ten times faster. (A factor of twenty was observed for extracting a single band from a .check file containing 1024 bands.)

Symmetry identification

The identification of symmetry operations in a Human-readable form of "6_3 axis through (0,0,0.25)" and similar has always been a little unreliable. The number of times I have thought it has been finally fixed is a little embarassing. Here I note two points. Firstly that the point through which the axis allegedly passes is not uniquely defined. Translational symmetry often means that axes occur in pairs, and anyway the point may be modified by an offset parallel to the axis. Secondly version 2.40d contains further improvements, so prior versions are known to err in some circumstances.

Units

C2x tries to work in V, e and A internally, and to convert those inputs which are in Ha or Bohr. It is likely that it gets confused sometimes, especially when reading files which can contain almost anything, such as xsf or cube files. The conversion factors which may need to be applied will depend on whether the data represents a potential, a volumetric density, a linear density, or something else. It would be wise to check for obvious errors. (Checks include that the integral of an electron density over a unit cell gives the expected number of electrons, for instance.).