Hello Charmm users,
I'm simulating a monoclinic crystal with P21 space group.
I used the following command to build the crystal:
crystal define Monoclinic 10.839 13.349 4.954 90 91.31 90
crystal build noper 1 cutoff 16
Crystal Write card unit 20
image BYSEgments xcen 0.0 ycen 0.0 zcen 0.0 select segid CARB end
Then update image atom lists
update inbfrq -1 imgfrq -1 ihbfrq 0 -
ewald pmewald kappa 0.34 fftx 32 ffty 32 fftz 32 order 6 lrc -
atom switch vatom vswitch cutnb 16 ctonnb 10 ctofnb 12 -
Error message occurs after energy command, showing:
***** LEVEL -5 WARNING FROM PME_column *****
***** no symmetry operations for column FFT yet*****
Could anybody tell me what is this error about. I have searched for it, but did not get any info about it.
The messages indicates that the COLFFT feature (designed to speed up PME) does not support symmetry operations with rotations, such as P21. Unfortunately, at the present time that can only be disabled at compile time, which means building a separate version of CHARMM without this feature. The details depend on the installation method (install.com or cmake configure); at the very least, FFTW, MKL, and DOMDEC must all be disabled, as they require the COLFFT feature.
Dear Dr. Venable,
Thanks for your advice. But I learned from Charmm website 'In order to use the Particle-Mesh Ewald (PME) electrostatics, CHARMM must be compiled with pref keywords COLFFT.' Since I am using PME method, what else could I do to avoid the error? (Is there something that can replace PME but reproduce same effects?)
That is incorrect (at least it should not be true); can you provide a more complete reference to where that is stated?
It is true that better performance can be achieved for PME via COLFFT combined with the FFTW library, either explicitly or via the Intel MKL version. But unless someone has broken the code, PME should function w/o COLFFT; there is an alternative option, ASYNC_PME, which also provides some speed up compared to the base PME implementation.
However, how to build that code branch is poorly documented, and not directly supported by a single command line option for either install.com or the newer cmake configure procedure.
COLFFT seems to be a specific requirement for PME with DOMDEC.
Right, an important aspect of that better performance is the DOMDEC engine, esp. with an FFTW library.
I've posted some build
command lines for non-COLFFT executables in the Installation forum.
Thank you Rick and Lennart,
I have successfully compiled new Charmm from your suggestions.
One issue is that volume of unit cell Charmm calculates is way smaller than it should be. For instance, at one time step, DYNA a= 11.21298 B = 13.80958 C = 5.12493,
DYNA Alpha = 90.00000 Beta = 91.31000 Gamma = 90.00000
and volume computed by charmm is 396.68519. By definition, volume=a*b*c*sin(beta)=793.4, which is twice larger than charmm volume. The crystal lengths are also a little off than experimental values. I'm only simulating one molecule in NPT ensemble with the P21 monoclinic crystal. But, I have seen people in the forum creating a whole unit cell from a single molecule with coor duplicate/oper command. I wonder why whether the volume issue is related with this? (If not, what could cause it)
Is it OK to simulate only one molecule to produce proper crystal effects(crystal dimensions, etc) with crystal define/build command which create only image atoms.
If you simulate only the asymmetric unit, then CHARMM computes that volume, and not the volume of the unit cell.
It should be noted that the value used for CRYSTAL BUILD CUTOFF can (and probably should) be larger than the list cutoffs CUTNB and CUTIM. For CRYSTAL BUILD, the value determines the list of available crystal transformations, and too small a value might leave out needed transformations.
I always preferred using the full unit cell for small molecule crystals, and sometimes multiple unit cells, esp. for force field tests. How much the molecules deviate from each other when more of them are real and not images can be useful information.