I am new to Avogadro (just started it today), so, sorry, if the question sounds silly: about how long the conformer search should run? Just ballpark: hours, days? And how do I know it is really running and not stuck somewhere? Molecule: C22H26BF2N8O14P3S, on laptop Intel i7, 1.7 GHz. Search parameters: MMFF94, convergence 10^-6u, steps limit 2500, 100 conformers, 25 steps per conformer, weighted rotor search.
Thank you!
Expected Behavior
Actual Behavior
Steps to Reproduce
Please upload files if appropriate here (or via file-sharing service like Dropbox or Pastebin)
That’s a fairly large molecule. Typically I monitor conformer search based on the number of rotatable bonds. But the question is what kind of search did you start? Open Babel (through Avogadro) supports several different options, including systematic search, which would be pretty exhaustive.
Pubchem is one large public database, if you know an identifier like the chemical (English) name, CAS registry number; InChI or SMILES string you can look up records. If small enough, and “organic enough” (i.e., salts like phosphates do not count), chances are that there already is a conformer to start with as 3D conformer. See for instance glucose with such data, and mycolactone with an explicit Conformer generation is disallowed since too many atoms, too flexible.
It needn’t be the conformer of lowest energy, and the conformer is the result of an affordable level of computation (MMFF94s force field, for details in J Cheminform (doi: 10.1186/1758-2946-3-32, open access), but depending on what you want to do good enough for a display on a poster, or serve as a starting point for additional work.
If you don’t want to save the .sdf generated by PubChem on the web site itself, Avogadro2 offers a download by name, too. If you need a batch of conformers about multiple molecules, a programmatic approach (for instance pubchempy and cirpy) may more suitable. The example of glucose is one of the rare instances where pubchem provides multiple conformers per record.
Thank you! As far as I understood, it is Monte-Carlo search (weighted rotor). Looking at the thread from July on the same topic, I suspect the search simply does not work, because nothing happens, and conformer analysis stays dim. The molecule is fluorescently labeled GTP. The thing I am trying to figure out if there is any chance for stacking BODIPY and guanine and if it gives any sizeable dip in energy
Please try a nightly build - there are continuous bug fixes, including in the conformer search. The current builds are essentially pre-releases of v2.1 which will be released on 23 October.
That’s going to be a tricky calculation. I would suggest at the least using the xtb program (or plugin). Standard force fields do not give accurate \pi-\pi stacking energetics. Personally, I’d rather approximate the potential BODIPY - guanine complex and then hand it off to xtb and then a DFT program like ORCA to optimize the geometry before determining energetics, e.g., 2.11. Counterpoise Corrections — ORCA 6.1.1 Manual
@ywoldman Some of force field methods are not prepared (parametrized) for boron (BODIPY) at all. The somewhat «salty / partially ionic character» of a charged BODIPY (after the treatment with \ce{BF3 \times Et2O}) could be an additional reason a force field based conformer search will not work. For pubchem – just checked again – both criterion 3 and 4 would be in opposition to run an optimization with their MMFF94s if boron is in place. I don’t know if substitution of the \ce{BF^-2} moiety by a methylene bridge as temporary placeholder during an exhaustive conformer search on side chains were permissible.
Open Babel will switch to UFF for conformer searches because of the boron. And it’ll be okay, but if you’re looking to understand pi-pi stacking, it’s good to at least use something like xtb-GFN2
Either I wasn’t aware of, or (more probable) I forgot the implemented logic of “openbabel’s fallback is UFF, and if necessary (e.g., for lack of parametrization) force field X is replaced by UFF”. With the archetypical BODIPY, I run
which by MMFF94 Force Field (mmff94) — Open Babel openbabel-3-2-0 documentation should preferentially issue a note, because boron is not one of the explicitly mentioned atoms. However, obabel (version 3.2.0 in Linux Debian) smoothly generates a .sdf, without any issue report to the CLI, nor non-blocking warning (like “kekulization failed”).
If this were an example “implicitly, openbabel replaces the force field by UFF”, I would welcome
a note like “instead of selected MMFF94, the optimization used UFF” to stderr / 2> if obabel is run on the CLI
if an optimization in Avogadro2 relies on openbabel’s logic .and. openbabel identifies the need to favor UFF over user selected MMFF94, a little note in Avogadro2 equally were welcome as feedback to the user.