From: Marcelo C. R. Melo (melomcr_at_gmail.com)
Date: Mon Feb 25 2019 - 10:23:20 CST
The kind of issue you are discussing was first saw when another researcher
was applying NAMD QM/MM to gaussian, and needed to make a modification to
the initial step of the simulation. At that time, we added a keyword called
"*qmPrepProc*", which receives an executable path (like a python script)
that is ran *before* the first step, and never again. This script receives
as an argument the path to the standard input file that NAMD creates for
ORCA (or any other code). This way, the very first orca input file can be
modified, and all following steps will be ran using the standard
NAMD-generated input file (and, as usual, will use the temporary files
generated in previous iterations).
I don't remember exactly what the application was at the time, probably
something to do with charge distribution, but it seems to me that the
solution could work for you too, without "hacking" a way around NAMD.
I think it is worth it to note that software like ORCA are very extensive
and can have very complex input files and options. NAMD's QM/MM was
designed to provide a general (and native) interface to MOPAC and ORCA, but
we would never replicate the *entire* configuration capabilities of
something like ORCA. That is why we designed the *custom* interface. This
not only serves to connect any QM code through a wrapper, but also allows
one to use a supported code when advanced configuration features are needed.
--- Marcelo Cardoso dos Reis Melo, PhD Postdoctoral Research Associate Luthey-Schulten Group University of Illinois at Urbana-Champaign crdsdsr2_at_illinois.edu +1 (217) 244-5983 On Mon, 25 Feb 2019 at 08:57, Gerard Rowe <GerardR_at_usca.edu> wrote: > Hi, > > When running BS calculations in Orca, there are two ways to go: > > 1. creating a BS guess for each calculation or > 2. reading a previously converged BS wavefunction. > > Proceeding with the default settings in NAMD QM/MM, you'll always follow > option #1. In that kind of calculation, you specify the high-spin > multiplicity in the charge/multiplicity line, and input the BS settings in > the %SCF block. This is somewhat wasteful, though, because every step of > your optimization has to find the BS solution. > > On the other hand, if you perform a single-point BS calculation and use > its resulting GBW file as the input for the next calculation, you would set > the spin multiplicity to whatever your BS solution was set to (if that > state happens to be a singlet, make sure you specify UKS in the input line). > > The hard part is tricking NAMD into reading the output of a single point > calculation during the QM/MM run. The procedure I figured out is awkward, > but it works. First, run a QM/MM calculation as your normally would, and > kill the job once you see that Orca has been launched. Then, go into the > folder containing the orca input file. Copy this input file along with the > pointcharge file into another folder. Modify the Orca input to perform a > BS calculation. Once this single-point calculation is complete, copy the > gbw file into the scratch folder that NAMD set up. NAMD doesn't clean up > these folders between runs or between iterations; it only overwrites files > as necessary. Make sure the gbw file name matches the QM input file name > (it's something like tmpout, if I recall correctly). > > From here, you will edit your namd input to specify the BS multiplicity, > and remove any broken symmetry/flipspin commands from the %SCF block. > You're reading in a converged wavefunction, so it will start with the BS > state. During the QM/MM run, you should dump the Orca output to another > text file so you can keep an eye on the Mulliken spin populations to ensure > you are still working on the BS surface. > > -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:* Saturday, February 23, 2019 3:34 PM > *To:* NAMD > *Subject:* namd-l: Fwd: QM-MM NAMD-ORCA broken symmetry > > > > ---------- Forwarded message --------- > From: *Francesco Pietra* <chiendarret_at_gmail.com> > Date: Sat, Feb 23, 2019 at 5:38 PM > Subject: QM-MM NAMD-ORCA broken symmetry > To: NAMD <namd-l_at_ks.uiuc.edu> > Sorry, orca requests nr electrons > fp > > Hi > Setting broken symmetry DFT with ORCA requires a block with multiplicity > for both parts. Setting that, and commenting out the line specifying > multiplicity in NAMD conf file, leads to crash. NAMD wants to see the > multiplicity. > > Is that any reason not to do like with MOPAC, i.e., setting the > multiplicity directly in the block to the QM program? > > As far as I can see in the lab, my system is bs, which can not be treated > with semiempirical. > > Thanks > > francesco pietra >
This archive was generated by hypermail 2.1.6 : Thu Dec 31 2020 - 23:17:10 CST