high rmsd for very similar conformations

[yangyinuo823]

Hello, I have two very similar conformations but with different atoms orders. I tried all three reorder methods, but they all give a relatively high rmsd (>1.1). I also tried some other ways like VMD to align and compute rmsd, it aligns horrible and also give ~1.1 rmsd. Usually I got very small rmsd(<0.2) for very similar conformations. So I'm curious would it be an algorithm issue or is there anything I did wrong? Thanks!

13
xyzfile1
C 1.2097486856 -0.3867939845 0.6046909467
C 0.6651571592 0.7684426688 -0.1714730055
C 0.4584113896 -0.6442611692 -0.6611185626
C -1.0801777070 -0.4495852324 -0.5280943789
N -1.5272833559 -0.0479567544 0.7832654551
C -0.8775857156 0.9359845078 -0.0479139089
H 2.2816087146 -0.5125012517 0.5133625296
H 0.8381537276 -0.6720196653 1.5825612231
H 1.3026362164 1.5291946097 -0.5973321022
H 0.9140290182 -1.1202720222 -1.5168514396
H -1.8004081836 -0.8509801979 -1.2272937384
H -0.9787367606 -0.3965316138 1.5579074763
H -1.4055531884 1.8472801049 -0.2917104947

13
xyzfile2
C 0.3114116448 -1.3780395165 -0.0083439827
C 1.0112907869 -0.0728758952 -0.2073982593
C 0.0751674372 1.0731587356 -0.6907890620
C -0.8039275932 0.8684571531 0.4828845776
N -1.3065298077 0.6948878594 -0.8579178147
C 0.1152823945 -0.2820384620 0.9886676410
H 0.9574955457 -2.1765490228 0.3346933322
H -0.4777429926 -1.7307430147 -0.6629963914
H 2.0882214945 0.0091565418 -0.2210706339
H 0.4299295208 1.9843305779 -1.1517959987
H -1.2853082407 1.5846683938 1.1339445335
H -1.4672059548 -0.2614129705 -1.1447095520
H 0.4058967646 -0.3843973798 2.0238506104

[nbehrnd]

One of the adjustable parameters is --reorder-method. It is true, on occasion the alignment by --reorder-method hungarian (the implicit default) suggested is not as good as anticipated (here: RMSD 1.195), but the program offers alternatives. The alignment by explicit --reorder-method distance for example assigns a RMSD equal to 0.001. In e.g., Jmol's simultaneous display of the two models calculate_rmsd.py aligned to each other, the two are practically indiscernible:

This likely is a problem of optimization encountered each time one starts in a local minimum and aims to identify an other, a deeper minimum (hopefully the global minimum). I do not attribute this as an error how calculate_rmsd.py works.

2022-03-03_data.zip

Side note: A thread like this one likely fits better as an issue, than discussion. The later, I speculate, is more suitable for feature requests.

[yangyinuo823]

Thank you so much for the quick and detailed reply! I'm confused why we got different results for the distance method?
I firstly tried default reorder method and get a rmsd of 1.195 (exactly same as yours).
Then I tried --reorder-method distance, it gives 1.114, which is quite different from yours (0.001).
Below are my inputs and outputs for all three reorder methods. I would very appreciate if you have any ideas why this happens! (I double check the xyzfiles and rmsd installation, no problem for them)

(base) yinuo@moria:~$ calculate_rmsd --reorder 1.xyz 2.xyz
1.1958459431299266
(base) yinuo@moria:~$ calculate_rmsd --reorder-method distance 1.xyz 2.xyz
1.1143562673873584
(base) yinuo@moria:~$ calculate_rmsd --reorder-method brute 1.xyz 2.xyz
1.1143562673873584

And I'm sorry for putting this at inappropriate place, thanks to let me know!

[nbehrnd]

At present, to change the reorder method, calculate_rmsd requires to explicitly deploy both the flag --reorder .and. a specific --reorder-method [hungarian, inertia-hungarian, brute, distance]. If these parameters are defined ahead of the two structure files to be aligned, their position in the sequence of the command is irrelevant.

Assuming running the program after the installation with pip:

$ calculate_rmsd --reorder-method hungarian --reorder 1.xyz 2.xyz 
1.1958459431299266
$ calculate_rmsd --reorder --reorder-method hungarian 1.xyz 2.xyz 
1.1958459431299266
$
$
$ calculate_rmsd --reorder --reorder-method distance 1.xyz 2.xyz 
0.0012379383034675595
$ calculate_rmsd --reorder-method distance --reorder 1.xyz 2.xyz 
0.0012379383034675595
$
$
$ calculate_rmsd --reorder --reorder-method inertia-hungarian 1.xyz 2.xyz 
0.0012379383034675595
$ calculate_rmsd --reorder --reorder-method brute 1.xyz 2.xyz 
0.0012379383034675595

(Linux Debian 12/bookworm (branch testing), python 3.9.10, rmsd 1.4 as installed from PyPi via pip.)

The documentation describes none and qml as options for --reorder-method, which I didn't use so far. The two apparently are not functional despite qml (version 0.2.1) is installed; thank you for leading to this find.

Side note: I retract my earlier argument. With the categories set, the discussion section may welcome posts like yours.
Note, on github, you may report multiple lines of code as a block enclosed with three grave signs in a separate line prior and after the content to present. At least for some languages, you may enable syntax highlighting if the opening three grave signs are followed by a tag like awk, python, fortran/f90, etc. For some reason, you can't use this markup in a reply sent via email, though.

[yangyinuo823]

This works! I really appreciate your help and detailed explanation! I'm not very familiar with github. Thank you for your helpful notes! And wish you a happy weekend!