My crystal is a metal-organic framework, and I want to use GULP to perform a series of optimizations. Before that, I think it’s necessary to make sure the code describes the crystal correctly.
there are 6 atoms in the asymmetry unit, and the space group is 225, here is the structure of the asymmetry unit:
the bonding is wrong in the output asymmetric unit, e.g., there are 6 bond types in the origin cif file, but the output one has only 4; and the H should only connect to C1 but it also connect to C2 in the output cif.
I also tried to grow the crystal, but the bonds between asymmetric units are absent.
Does anyone know how to fix the bonding problem and how to make the asymmetric units connected?
my code: myfit.gin (3.6 KB)
and output file: output.got (61.6 KB)
and the GULP version is 6.2.0.
Thank you in advance.
Dear Wang,
The structure of your MOF is fine, which can be seen from adding “dist” to look at the distances in the structure. The issue is the specification of the bonds for fitting having the wrong numbers. It’s hard to get the numbers you need by hand since they refer to the full cell. The best way to see the bonding connectivity is to add the keyword “molq” to automatically generate bonds & then to dump it to the restart file using “dump connectivity”. This then provides information on the correct numbers & cell images. Of course if you fit the structure then you’re implicitly fitting the bonds as well anyway.
Regards,
Julian
Thank you for your reply. My problem has been resolved. This ‘dump’ command automatically generates over 900 bonds with the default bond type single.
now I want to change the bond type to resonent since parts of the bonds should be. then I used the option ‘bondtype’:
bondtype Cu core Cu core single
bondtype Cu core O core single
bondtype C1 core H core single exo
bondtype C2 core C1 core resonant cyc
bondtype C3 core C2 core single exo
bondtype O core C3 core resonant
however, it seems the bond type cannot be written to the dump file. secondly, I tried to just put the above lines in the input files after the ‘connect’ part to run fit, but the bond type in the output file didn’t change.
I think it’s impossible to revise the bond type by hand, do you have any idea to change the bond type automatically? thank you again.
I am afraid you need to generate a representation of your system in P1 space group , specify all bonds yourself an disable GULP bond creation. I am still not sure how to set up cross- cell bonds in this way.
Related question - why do you need to specify bond type ? It play rule only for some force fields (UFF). Eg. gaff/gaff2 or Dreidin recognize forces from atom types and ignores bond orders … Even for uff I belive you can specify the forces manualy = ignore order and let GULP find them.
As I can’t see your input I’m not sure what the issue is for your input. However, here is an simple example of how to automatically generate bonds and set the type using “bondtype” at the same time:
grad conp molmec bond
cell
25.8556 25.8556 25.8556 90 90 90
frac
Zn core 0.293477 0.293477 0.293477
C core 0.111460 0.250000 0.250000
C core 0.053860 0.250000 0.250000
C core 0.217510 0.217510 0.473430
O core 0.250000 0.250000 0.250000
O core 0.219370 0.219370 0.366110
H core 0.195600 0.195600 0.455200
space
F M -3 M
bondtype Zn Zn double
dump connect bondtest.res
In this example I use “molmec” to find all the bonds & use “bondtype” to set Zn-Zn bonds to be double bonds (NB this is just an example of how to use the command rather than suggesting that Zn-Zn double bonds are a sensible thing to have!). If you look in the restart file generated then you will see that the Zn-Zn bonds are indeed now dumped as being double bonds.
Hope that helps.
Julian
I saw the difference between ‘molq’ and ‘molmec’ is the latter subtracts the Coulomb terms, which I think I can add back in the restart file, and to do other calculations.
I have tried your example, and it works. I have attached my input file because I exactly followed your example, but my input file doesn’t work.
Dear Wang,
Apologies but there was a hiccup in the code for cases where there are 2 different atom types. I’ve now fixed this in the version 6.2 for download and in 6.3 which is now available.
Sorry for the issue, but hopefully this is now resolved.
Best regards,
Julian
