Gmx covar: error due to the PBC

User discussions
1

Dear Gromacs users !

Having the structure composed of C-alpha atoms and the corresponded trajectory I try to perform the following steps to fix the PBC of the trajectory for PCA analysis of this system.

This is step by step protocol

  1. gmx trjconv -s reference_CA.pdb -f merged_ALL.trr -o 1.trr -pbc mol

center molecule

  1. gmx trjconv -s reference_CA.pdb -f ./1.trr -o 2.trr -center

remove pbc

  1. gmx trjconv -s reference_CA.pdb -f ./2.trr -o 3.trr -pbc whole

realign snapshots

  1. gmx trjconv -s reference_CA.pdb -f ./1.trr -o 2.trr -fit rot+trans

I opened in VMD the resulted trajectory and visually everything looks OK without any pbc artifacts.

However performing PCA in the first step
gmx covar -s ./reference_CA.pdb -f ./2.trr -o ./eigenval.xvg

there is always the same error:

Program: gmx covar, version 2021.4-Ubuntu-2021.4-2
Source file: src/gromacs/gmxana/gmx_covar.cpp (line 327)

Fatal error:
Invalid periodic boundary conditions: Only triclinic boxes with the first
vector parallel to the x-axis and the second vector in the xy-plane are
supported.

How could the issue be fixxed ?

Many thanks in advance!

2

Does it work if you use the .tpr file instead of the pdb file? I.e.,
gmx covar -s topol.tpr -f 2.trr -o eigenval.xvg

I haven’t looked closely at the code or the error, but my guess is that there is no proper PBC information in the reference file that you are using.

3

Thank you very much for your kind repply !
Actually I do not have a pdb since this was calculated in amber ! I’ve used this protocol many times and this is the first time when I have an issue …

Would it be it possible to fix pbc in the pdb file using some gromacs utility like editconf ??

4

If you use, e.g., gmx dump you should be able to find the box dimensions of the first frame in the trajectory. Hopefully it would work if you use that as box dimensions with gmx editconf.

If you’ve used this protocol before and it has worked, you could first compare the pdb file you are using now to those that have worked before. If there is no apparent difference in the PBC data there is probably another issue.

5

Actually I could not find a difference … I also tried to align reference along the principal axe using editconf -princ but it does not change anything. I also tried several different references and the error is persist. May be there is a bug in my version of gromacs ?

6

It would definitely be worth checking if it works in 2024.2, but since it has worked for you before I’m afraid it might not help.

What is the shape of your periodic box (in the .trr file and in the .pdb file, if there is one at all there)?

7

I checked it in VMD loading structure and the trajectory and it looks rectangular and everything also looks to be correct without any jumps across etc

8

I think (but may be wrong) it will usually look rectangular in VMD. It might be more informative to check the actual values of the periodic box shape in the trajectory. gmx dump can be used for that.

9

so assuming I have a trr and corresponded pdb what will be the full command using gmx dump to obtain the info about PBC vectors and the snapshot ?

10

I must admit I’m not sure about the PDB file. I guess it would be the CRYST1 field with dimensions and angles.

To get the data from the .trr you can use gmx dump -f 2.trr | less and then you can view all the contents of the file (if it’s called 2.trr). For every frame, the PBC info is found in the box (3x3) field. For example,

   box (3x3):
      box[    0]={ 3.00000e+00,  0.00000e+00,  0.00000e+00}
      box[    1]={ 0.00000e+00,  3.00000e+00,  0.00000e+00}
      box[    2]={ 0.00000e+00,  0.00000e+00,  3.00000e+00}

would be a cubic box with 3 nm sides.

11

Okay, so this is it

merged_ALL.trr frame 0:
natoms= 188 step= -1 time=2.1150000e+03 lambda= 0
box (3x3):
box[ 0]={ 1.09726e+01, -1.76640e-14, 1.82731e-15}
box[ 1]={ 1.35400e-14, 1.10870e+01, -7.23157e-15}
box[ 2]={-1.16679e-14, 9.82559e-15, 1.47502e+01}

12

That’s probably the explanation then. In some step (possibly going from Amber to GROMACS) the box vectors have been messed up. All those values < 1e-13 should almost certainly be 0. I think the correct box vectors would have been:

box (3x3):
box[ 0]={ 1.09726e+01, 0.00000e+00, 0.00000e+00}
box[ 1]={ 0.00000e+00, 1.10870e+01, 0.00000e+00}
box[ 2]={ 0.00000e+00, 0.00000e+00, 1.47502e+01}

But I’m not sure how to fix this at this point.

You might be able to find where the error occurred by closely checking the Amber input and output (I don’t know how) as well as the values after converting to GROMACS trr before any other treatment (e.g., PBC treatment and centering).

13

Okay, thank you very much !
Actually if I do not do any PBC threatmenat of the trajectory using gmx trajconv the values are still the same

natoms= 188 step= -1 time=2.1150000e+03 lambda= 0
box (3x3):
box[ 0]={ 1.09726e+01, -1.76640e-14, 1.82731e-15}
box[ 1]={ 1.35400e-14, 1.10870e+01, -7.23157e-15}
box[ 2]={-1.16679e-14, 9.82559e-15, 1.47502e+01}
So this is the first time when I have this issue ( the trr file was produced via cpptraj software of amber tools anyway … )

14

I guess there is some kind of dump tool for Amber as well. It would be interesting to see if the box vectors are correct in the Amber trajectory. My guess would be that it is a float precision problem and that either Amber or cpptraj have turned the 90 degree angles into almost 90 degree angles.

15

Right, thank you very much ! I believe it could be related to using different version of cpptraj (with parallelisation) for this conversion. I will check it now ;-)

16

well checked it extensively. indeed sometimes the bug persist. may be there are some gromacs tools which cool reset completely PBC vectors from any trr file ?

17

There are no tools that I can think of. It would be possible to write one suitable for this case, but in general it is risky modifying the periodic box of an existing trajectory.

There are two solutions to this, as I see it:

  1. Fix the conversion tool (cpptraj) so that such obvious float precision errors are avoided, e.g., set the box vector value to 0 when it’s < 1e-13.
  2. Set a tolerance in the GROMACS tools (at least gmx covar) so that such cases do not trigger this fatal error. I guess that the tool would function normally.

Both these solutions would take a while before they are available to you.

18

Okay thank you very much ! So in the present version of gmx covar there is no explicit option to ignore this warning for PBC, isn’t it ?

19

No, not yet at least. If you want to experiment, I don’t think it would be difficult for you to find where in the code this check is located and introduce a tolerance instead of a strict check. You could even try disabling the check completely to see how that would work for your system.

1 Like