From: Francesco Pietra (chiendarret_at_gmail.com)
Date: Fri Feb 15 2019 - 02:34:56 CST
The only possible way I can think about mitigating the computational burden
is shrinking the qm part by retaining, for each protein residue coordinated
to the metal ions, only the charge group nearest to the metal ions. While
waiting for smarter ideas from o.p., we will see whether this is enough
and, if so, whether the biochemistry is still respected
francesco
On Thu, Feb 14, 2019 at 11:34 PM Francesco Pietra <chiendarret_at_gmail.com>
wrote:
> I dare going back a few weeks, when I was advised by Marcelo that a MPI
> program like ORCA cannot be run within another MPI program like NAMD. Now,
> faced by the slowness of (very highly tuned) QM-MM on one node with my high
> (very high!) spin large system (multinode namd nightbuild, SCF OK in 174
> cycles but only ENERGY 5 in five hours) I tried with four nodes, namd2/12
> mpi. Notice that, in order to speed up initially the simulation, I used a
> very low level of DFT, probably too low for a system like that.
>
> Probably I had forgot Marcelo's warning because my recent observation that
> there is no gain going to more than 8 cores with orca was wrong. It was
> based on the small Polyala system of the tutorial. With my large system,
> all 34 process were actively doing their job, much faster than with eight
> processes.
> Suddenly I remembered Marcelo and ssh into each one of the four nodes
> confirmed that each core was occupied by namd.
>
> This long and boring story to conclude that in my hands, for the time
> being, common systems of biochemical interest embodying high spin Tmetals
> are hard to investigate by QM-MM, unless one has unlimited access to one
> good node.
> However, there are reports of such studies with high spin multi Tmetals.
> How could that work be carried out? I tried epr-silent antiferromagnetic
> coupling but, with the odd number of electrons of my system, a singlet was
> refused by QM-MM. Because of that, probably broken-symmetry will not help.
> Any idea?
> All the best
> francesco
>
> On Thu, Feb 14, 2019 at 6:33 PM Marcelo C. R. Melo <melomcr_at_gmail.com>
> wrote:
>
>> Thank you for the input, Gerard.
>> I was about to look into that myself since I did not understand the
>> source of the problem.
>> best
>> ---
>> 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 Thu, 14 Feb 2019 at 10:39, Gerard Rowe <GerardR_at_usca.edu> wrote:
>>
>>> Francesco,
>>>
>>> You probably already figured it out, but for others who may be reading,
>>> the error you experienced was an Orca syntax error. The %maxcore ### line
>>> is a single-line command that doesn't get terminated with "end". Only input
>>> blocks like SCF, BASIS, and PAL should be terminated with "end". It's
>>> confusing because it starts with %, but "%maxcore ####" is setting a global
>>> variable rather than initializing an input block.
>>>
>>> -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:* Thursday, February 14, 2019 9:46 AM
>>> *To:* Eric Smoll; melomcr_at_gmail.com
>>> *Cc:* NAMD
>>> *Subject:* Re: namd-l: About restarting QM-MM simulation
>>>
>>> On a fresh approach, a few hours later, the following interpretation
>>>
>>> qmConfigLine "! UKS BP86 RI SV def2/J enGrad SlowConv"
>>> qmConfigLine "%%maxcore 2500 %%pal nproc 34 end"
>>> # qmConfigLine "%%pal nproc 34 end"
>>>
>>> allows the simulation running.
>>> francesco
>>>
>>> On Thu, Feb 14, 2019 at 11:17 AM Francesco Pietra <chiendarret_at_gmail.com>
>>> wrote:
>>>
>>> Hi Eric, perhaps you can help me further about an error message
>>> concerning input to ORCA that is unclear to me
>>>
>>> setting in namd conf file about orca:
>>>
>>> qmConfigLine "! UKS BP86 RI SV def2/J enGrad SlowConv"
>>> qmConfigLine "%%maxcore 2500 end"
>>> qmConfigLine "%%pal nproc 34 end"
>>> qmConfigLine "%%scf MaxIter 5000 end"
>>> qmConfigLine "%%output Printlevel Mini Print\[ P_Mulliken \] 1
>>> Print\[P_AtCharges_M\] 1 end"
>>>
>>>
>>> Error shown in /0/..TmpOut
>>> [file orca_main/maininp1.cpp, line 14628]: ERROR: expect a '$', '!',
>>> '%', '*' or '[' in the input
>>>
>>> By commenting out the line
>>> qmConfigLine "%%maxcore 2500 end"
>>> the simulations starts regularly. The default mem 1024 gave rise to
>>> warning in /0, while 2500 per core corresponds to less than 75% mem
>>> available on the node.
>>> I must have been unable to interpret correctly the Example furnished by
>>> ORCA, or there is something else that I don't understand.
>>> Example:
>>> ! DLPNO-CCSD(T) def2-TZVP def2-TZVP/C
>>> %maxcore 3000
>>> %pal
>>> nprocs 6
>>> end
>>> Thanks for advice
>>> francesco
>>>
>>>
>>>
>>> On Wed, Feb 13, 2019 at 7:48 PM Eric Smoll <ericsmoll_at_gmail.com> wrote:
>>>
>>> Hi,
>>>
>>> You asked how to increase the number of SCF iterations above the
>>> default. Try something like this:
>>>
>>> %scf
>>> MaxIter 500
>>> end
>>>
>>> Best,
>>> Eric
>>>
>>> On Wed, Feb 13, 2019 at 8:34 AM Francesco Pietra <chiendarret_at_gmail.com>
>>> wrote:
>>>
>>> Hello
>>> How can NAMD-ORCA QM-MM simulations be correctly restarted? I mean in
>>> the context of namd.config in Example1 tutorial:
>>>
>>> structure XXX_A1_box_ion.psf
>>> coordinates XXX_A1_box_ion.pdb
>>>
>>> # Output Parameters
>>> binaryoutput no
>>> outputname XXX_A1_out
>>> outputenergies 1
>>> outputtiming 1
>>> outputpressure 1
>>> binaryrestart yes
>>> dcdfile XXX_A1_out.dcd
>>> dcdfreq 1
>>> XSTFreq 1
>>> restartfreq 100
>>> restartname XXX_A1_out.restart
>>>
>>>
>>> In particular when no SCF convergence was not yet reached (in favorable
>>> cases, info says that SCF convergence is close to be reached), so that
>>> XXX_A1_out.restart was not provided.
>>>
>>> I was also unable to find on ORCA manual how to increase the number of
>>> SFC iterations above the default 125.
>>>
>>> Thanks for advice
>>> francesco pietra
>>> PS I understand that the ORCA calculation can be carried out separately
>>> but I have some reasons now to let NAM-ORCA working together.
>>>
>>>
This archive was generated by hypermail 2.1.6 : Tue Dec 31 2019 - 23:20:31 CST