From: Francesco Pietra (chiendarret_at_gmail.com)
Date: Mon Mar 25 2019 - 13:20:49 CDT
Gerard, by the way could you instruct me about the best way to use the qmmm
output of orca in the /0 folder for restarting as a pure qm calculation
using the qmmm_0_input.gbw file? That could allow me to usa more
appropriate settings.
Thanks
francesco
---------- Forwarded message ---------
From: Francesco Pietra <chiendarret_at_gmail.com>
Date: Mon, Mar 25, 2019 at 5:09 PM
Subject: Re: namd-l: About changing charge/multiplicity during QM-MM
To: NAMD <namd-l_at_ks.uiuc.edu>, Gerard Rowe <GerardR_at_usca.edu>
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