Thanks to visit codestin.com
Credit goes to github.com

Skip to content

cartesian_to_irc produces 180 degree dihedrals with random sign #52

@AlexB67

Description

@AlexB67

Hello, I hope I can explain this right, but I observed the issue as described in the title. Take ethane as an example. it produces the following coordinates:

New internal
  (redundant) coordinates: 28
*************************************
  7 bonds / Å
*************************************
  (   0,   1)        1.4613
  (   0,   2)        1.0941
  (   1,   3)        1.0941
  (   0,   4)        1.0941
  (   1,   5)        1.0941
  (   0,   6)        1.0941
  (   1,   7)        1.0941
*************************************
  12 angles / °:
*************************************
  (   1,   0,   2)  111.84
  (   0,   1,   3)  111.84
  (   1,   0,   4)  111.84
  (   2,   0,   4)  107.00
  (   0,   1,   5)  111.84
  (   3,   1,   5)  107.00
  (   1,   0,   6)  111.84
  (   2,   0,   6)  107.00
  (   4,   0,   6)  107.00
  (   0,   1,   7)  111.84
  (   3,   1,   7)  107.00
  (   5,   1,   7)  107.00
*************************************
  9 dihedrals / °
*************************************
  (   2,   0,   1,   3)   -60.00
  (   3,   1,   0,   4)    60.00
  (   2,   0,   1,   5)   180.00
  (   4,   0,   1,   5)   -60.00
  (   3,   1,   0,   6)   -180.00
  (   5,   1,   0,   6)    60.00
  (   2,   0,   1,   7)    60.00
  (   4,   0,   1,   7)  -180.00
  (   6,   0,   1,   7)   -60.00
*************************************

If you run cartesian_to_iirc successive times the outcome of the 180 dihedral angles flip sign. it may give

 (   2,   0,   1,   5)   180.00
 (   3,   1,   0,   6)  -180.00
 (   4,   0,   1,   7)  -180.00

or sometimes

(   2,   0,   1,   5)  -180.00
(   3,   1,   0,   6)  180.00
(   4,   0,   1,   7)  180.00

but only for the 180 degree case.

As you can imagine this can pay havoc with geometry optimization because dihedrals that have flipped 360 degrees during a geometry optimization step can give rogue values for dq,

one can get dq = 2 pi when it should have been dq = 0, or something very small.

Yesterday, I put a plaster in my own code to detect this flip, so I could work around the issue. Of course, it would be nice to see what the issue in libirc is.

Thus far, I've made the following change; It works in all my tests so far, but not knowing your code base very well I don't if there could be unwanted consequences

In constsnts.h I added

// dihedrals near 2 pi
constexpr double dihedral_near_180_tol{1e-6};

and in connectivity.h I changed the following lines, around 440 thereabouts

// Compute dihedral angle in radians (in the interval [-pi,pi])
  double angle{std::atan2(y, x)};
  
  if (std::fabs(std::fabs(angle) - tools::constants::pi) < tools::constants::dihedral_near_180_tol) 
        angle = std::fabs(angle);

  return angle;

What do you think ?

Best regards.

oh ad thanks for the library, great stuff.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions