From: Francesco Pietra (chiendarret_at_gmail.com)
Date: Thu Feb 14 2019 - 16:34:46 CST
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