Closed BradenDKelly closed 2 years ago
I just noticed that the two $wall
's is completely different for the xyz
and pdb
file, despite them being the same coordinates
Dear Braden,
I am pretty sure the issue is related to your starting structure. Have you tried optimizing the starting structure with GFN2-xTB first? Then you can entirely avoid GROMACs and coordinate conversion as a source of error. Also, sometimes the autogenerated $wall is too small, which leads to unstable simulations (like in your second example). Here it helps to use -wscal 1.2 or 1.4 to increase the size of the cavity. Edit: Since you have plain organic molecules, I would at least run the tests using -gfnff as this will be ~1000 times faster (or at least -gfnff//gfn2). Cheers, Jan
Please, never start user-space programs with elevated privileges. crest
is going to create a whole bunch of files and subprocesses using the same privilege level.
Note that wall potentials are always centered on the origin, for the NCI mode the center of mass of your molecule should be close to the actual coordinate system origin.
@drmewes @awvwgk I will center the molecules, I was curious about this, which is why I mentioned it. That could explain things. I don't plan on using gromacs for the initial starting coordinates in the future, but since i have several thousand... so it goes. I mostly just use it to make the a dimer that doesn't have substantial atomic overlap. My suspicion was that using crest enmin.xyz -omd
was essentially just centering the dimer, with the added burden of doing a conformation search as well. i noticed the coordinates in crest_best.xyz
were near the origin.
The use of sudo
is necessary at the moment and I too find it unsavory.
I'll second @awvwgk's comment. The problem here are the shifted coordinates of your system with the wall potential close to the origin. You can see that the calculations crash in the xtb.out
of the trial MDs. The different wall potential sizes for pdb
and xyz
input formats could be a bug (probably the pdb
coordinates are not shifted to the origin before determination of the wall potential). For the xyz
input the generated wall potential size looks about right, but if you observe any convergence problems refer to @drmewes suggestion of the -wscal
command first.
Also, there is no -omd
command in crest.
Also, there is no
-omd
command in crest.
This is true, and kind of funny. I lose track of when I am using CREST or xTB. Telling CREST to do -omd
just triggers xTB
. CREST is smarter than me, in that regard
It does generate errors though, but after awhile it gets around to using xTB to do -omd
Thanks fellows, it works fine now when I center at 0 first. It is interesting that gfn2 predicts pi-pi stacking as the best dimer and gfnff predicts stacked, but then paracetamol rotated 90 degrees so its edge is against the flat face of anthracene. Which is best has to be answered using DFT or CCSD(T).
Any plans on making CENSO work with freeware QM programs, like PSI4?
Cheers,
Braden
Any plans on making CENSO work with freeware QM programs, like PSI4?
Orca is free for academic use and supported in CENSO.
Any plans on making CENSO work with freeware QM programs, like PSI4?
Orca is free for academic use and supported in CENSO.
I am not academic :(
Well, can't help with that.
Of course, you are welcome to contribute Psi4 support to CENSO.
Well, can't help with that.
Of course, you are welcome to contribute Psi4 support to CENSO.
I may be able to pull that off. It has been awhile since I got SIGSEGV.
Hello,
I get the following error when trying to use
-nci
mode on pairs of dimers.Here is the command line of the call and error:
Here is a sample pdb file:
If I use instead an xyz file I get the following error:
And here is the xyz file:
What I have found does work, is first running
crest enmin.xyz -omd
, and follow this withcrest crest_best.xyz -nci
, but I would think I should be able to just skip to the nci. It makes me feel like something else is going on that I should make sure is in order.For further information: the pdb files are generated by gromacs, that is what makes and does a basic steepest descent energy minimization on the dimer pairs, and it then converts the .g96 file to a pdb (and does a bad job of it, I have a script to add in the 77-78 column the element names when I then use
iodata
to convert thepdb
toxyz
.Finally, the coordinates are so large because gromacs 2021 won't run proper vacuum, so I put the dimers in a really large box and run it with PBC (the images are so far away, they will never be interacted with). Perhaps it is the large coordinates throwing off the
-nci
call? but then, I would expect that to also mess up the-omd
call too.