Re: About changing charge/multiplicity during QM-MM

From: Francesco Pietra (chiendarret_at_gmail.com)
Date: Thu Mar 28 2019 - 16:19:01 CDT

Hi Gerard
If it is a duplicate of mail that I am unable to trace, excuse me.

The point is that, in my hands, standalone orca continues to create a gwb
file even though it was deleted, trying to autostart and not finding what
was expected.
Therefore, do you know how to insert the keyword "noAutoStart"? (mentioned
in orca's documentation about restarting).
The keyword was refused, although I tried in many ways, the most obvious
one being
%scf NoAutostart end

Thanks
francesco

On Tue, Mar 26, 2019 at 10:24 PM Gerard Rowe <GerardR_at_usca.edu> wrote:

> Unless your QM region is prohibitively large, it might be easier to just
> perform a single point calculation from scratch with the coordinates in the
> input file (i.e., remove the GBW file). That should avoid any issues.
>
> ------------------------------
> *From:* Francesco Pietra <chiendarret_at_gmail.com>
> *Sent:* Tuesday, March 26, 2019 4:55 PM
> *To:* Gerard Rowe
> *Subject:* Re: namd-l: About changing charge/multiplicity during QM-MM
>
> Gerard
> With full path to orca (4.1.1, the same path user for namd qmmm) same
> problem about the executable. In addition, a (for me) confusing allusion
> to basis sets.
> francesco
>
> WARNING!!!!!!!
> Your GBWFile is either corrupt or from a different ORCA version!
> Please be VERY careful with your calculation results!!!
>
> Data_size, sizeof( TOrcaInfo ): 497844, 491312
> ... Fine, the calculation information was read
> ... Fine, the file contains a basis set
> [file orca_tools/Tool-GTO-Bases/basissets.cpp, line 703]: TBasisList:
> Unable to read number of basis sets!
>
>
> On Tue, Mar 26, 2019 at 6:09 PM Gerard Rowe <GerardR_at_usca.edu> wrote:
>
> Hmm, it kind of looks like you either have a different number of atoms in
> your input than the program expects, or there are two different versions of
> orca installed on your system. You could try specifying the full path of
> Orca when running the program. That's the recommended way to do it for
> oMPI purposes, anyways.
>
> ------------------------------
> *From:* Francesco Pietra <chiendarret_at_gmail.com>
> *Sent:* Tuesday, March 26, 2019 12:35 PM
> *To:* Gerard Rowe
> *Cc:* NAMD
> *Subject:* Re: namd-l: About changing charge/multiplicity during QM-MM
>
> Hi Gerard:
> I copied the files that you indicated to a new folder. Then I modified
> qmmm_0.input by deleting "enGrad" from
> the first line of the .input file "! UKS BP86 RI SV def2/J enGrad KDIIS
> SOSCF"
> saving it as qmmm_0.noGrad.input, then launched a job
>
> srun orca qmmm_0.noGrad.input > qmmm_0.noGrad.log
>
> It crashed with message from .log file:
>
> Checking for AutoStart:
> The File: qmmm_0.noGrad.input.gbw exists (it was renamed by the system)
> Trying to determine its content:
>
> Checking for AutoStart:
> The File: qmmm_0.noGrad.input.gbw exists
> Trying to determine its content:
> ... Fine, the file contains calculation information
> ... Fine, the file contains calculation information
> ... Fine, the file contains calculation information
> ... Fine, the file contains calculation information
>
>
> WARNING!!!!!!!
> Your GBWFile is either corrupt or from a different ORCA version!
> Please be VERY careful with your calculation results!!!
>
> Data_size, sizeof( TOrcaInfo ): 744532, 491312
> ... Fine, the calculation information was read
> ... Fine, the file contains a basis set
>
> WARNING!!!!!!!
> Your GBWFile is either corrupt or from a different ORCA version!
> Please be VERY careful with your calculation results!!!
>
> Data_size, sizeof( TOrcaInfo ): 744532, 491312
> ... Fine, the calculation information was read
> ... Fine, the file contains a basis set
> [file orca_tools/Tool-GTO-Bases/basissets.cpp, line 706]: Wrong number of
> basis-sets stored!
>
> [file orca_tools/Tool-GTO-Bases/basissets.cpp, line 706]: Wrong number of
> basis-sets stored!
>
> [file orca_tools/Tool-GTO-Bases/basissets.cpp, line 706]: Wrong number of
> basis-sets stored!
>
> [file orca_tools/Tool-GTO-Bases/basissets.cpp, line 706]: Wrong number of
> basis-sets stored!
> ____
> The .err file said I/O operation failed.
> _________
>
> I don't understand that "Wrong number of basis set". The namd-qmmm
> simulation had been interrupted by the walltime.
> Could that be a reason for orca corrupted files?
>
> thanks
> francesco
>
>
>
> On Mon, Mar 25, 2019 at 7:34 PM Gerard Rowe <GerardR_at_usca.edu> wrote:
>
> Francesco,
>
> It sounds like you may have a fortunate outcome. I don't know the nature
> of your redox partner, but it's not an unreasonable assumption that the
> spin state will be the same between reactant and product if your partner
> becomes a ligand. If the redox partner started as a radical and became a
> closed-shell molecule, your final wavefunction is probably going to behave,
> and the trajectory could be well-suited for analysis through molecular
> orbital plots or spin-density plots. I think the most useful information
> will come out of spin density for a redox reaction. Things get more
> complicated (but not impossible) if the redox partner has unpaired
> electrons in it.
>
> As for carrying out stand-alone Orca calculations from the temp folder
> files of QM/MM, you should copy the inp, gbw, and point charge files into a
> new folder. Unless you have a lot of experience with QM programs, I'd
> stick to single point calculations here because you would have to play a
> tricky game of atomic restraints for QM geometry minimization.
>
> Your choice of level of theory is pretty good for QM/MM, but if I were
> trying to get a more reliable wavefunction, I'd probably change the basis
> set to def2-svp, and possibly specify def2-tzvp for the metal ion. If you
> don't have restrictions on how much CPU time you use for QM/MM, you may
> also play around with other local DFT functionals like PBE or M06L to see
> if they lead to different equilibrium structures. M06L, in particular, is
> parameterized to handle non-covalent interactions.
>
> -Gerard
>
>
>
>
> ------------------------------
> *From:* Francesco Pietra <chiendarret_at_gmail.com>
> *Sent:* Monday, March 25, 2019 12:09 PM
> *To:* NAMD; Gerard Rowe
> *Subject:* Re: namd-l: About changing charge/multiplicity during QM-MM
>
> Gerard:
> The redox partner is included but, regrettably, I have not yet carried out
> an analysis of what orca could tell. I simply observed that now the iron
> ions and the redox partner have reached a bonding distance, which remains
> stable on long QM-MM simulations, and the type of complex that is formed is
> experimentally known to have FeIII, never FeII. So, I came here much too
> early with my question, but, to go on, I'll take into account what you
> said. At any event the type of ligands of the Fe ions (in a protein) are
> for high spin, which over-complicates the matter. In addition, the
> simulation, because of the type and size of the system, was started at
> SlowConv but was continued at SOSCF in order to get convergence . All over
> it was at what might well be a too low level of DFT ("! UKS BP86 RI SV
> def2/J enGrad KDIIS SOSCF").
> Thanks
> francesco
>
> On Mon, Mar 25, 2019 at 3:53 PM Gerard Rowe <GerardR_at_usca.edu> wrote:
>
> Francesco,
>
> If your metal ion is definitely undergoing redox change, that's going to
> be very difficult to treat with QM/MM unless you have also included the
> redox partner in the QM region. Even then, it's going to be problematic
> because the spin state of your resulting system is unlikely to be
> reasonable. This is especially true if your final system is supposed to
> have unpaired electrons in different regions that aren't in communication
> anymore. What kind of system are you studying?
>
> I can imagine two scenarios where this will work out:
>
> 1. Your Fe(II) state is low-spin d6 (singlet) and the redox partner
> is a doublet. In the product state, The Fe(III) is a low-spin doublet and
> the redox partner is now a singlet.
> 2. Your Fe(II) state is high-spin d6 (sextet) and the redox partner is
> a singlet. In the product state, The Fe(III) is a high-spin quintet and
> the redox partner is now a doublet.
>
> If scenario 1 applies, you're in luck, and the spin system will be
> reasonable. If it's scenario 2, you're going to run into serious issues
> unless the redox partner happens to be bound to the metal. Long-range
> separation of unpaired spin in a DFT calculation often leads to problems
> and non-physical solutions. You can check the spin density of your
> resulting wavefunction in a similar way that you can visualize molecular
> orbitals.
>
> -Gerard
>
> ------------------------------
> *From:* owner-namd-l_at_ks.uiuc.edu <owner-namd-l_at_ks.uiuc.edu> on behalf of
> Francesco Pietra <chiendarret_at_gmail.com>
> *Sent:* Monday, March 25, 2019 3:16 AM
> *To:* NAMD
> *Subject:* namd-l: About changing charge/multiplicity during QM-MM
>
> I dare posing a general question on QM-MM, surely a naive question to
> those experienced with QM-MM (I am doing such simulations for the first
> time).
>
> I am observing a change in my metalloprotein system where apparently the
> iron ions become bounded to other ligands, changing from FeII to FeIII. The
> overall charge/multiplicity is not maintained, as far as I can understand.
> Nonetheless, ORCA is repeating its SCF cycles, converging after a number of
> cycles. I have already restarted the simulation six times for 24hr on 36
> cores with the same settings, in particular as to the charge and
> multiplicity, and the structure of the complex is no more changing, as far
> as it can be judged from geometry. I can't figure out how the system
> readjusts itself so that the QM calculation can go on.
> Thanks for any comment
> francesco pietra
>
>

This archive was generated by hypermail 2.1.6 : Thu Dec 31 2020 - 23:17:10 CST