Re: About restarting QM-MM simulation

It's hard to give scientific advice, but on the technical side, you can use NAMD-multicore in a cluster, and allow ORCA (with its intrinsic MPI infrastructure) to use as many nodes as you give it.

As I mentioned before, you will need to write some script to pass ORCA a "machinefile", getting the list of available nodes from your cluster (which different cluster makes available in different ways), and removing from the list the node where NAMD is running, to avoid them fighting for the same cores.

This would allow you to take advantage of ORCA's scalability for as much as possible, depending on the available hardware and size of QM region.

As for the science/system choice, I'll tell you this, keep link atoms as far away as possible from regions of interest. They are probably one of the largest (if not the largest) perturbation to the QM system.

Best,

Marcelo

---

Marcelo Cardoso dos Reis Melo, PhD

Postdoctoral Research Associate

Luthey-Schulten Group

University of Illinois at Urbana-Champaign

crdsdsr2@illinois.edu

+1 (217) 244-5983

On Fri, 15 Feb 2019 at 02:35, Francesco Pietra <chiendarret@gmail.com> wrote:

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@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@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@illinois.edu

+1 (217) 244-5983

On Thu, 14 Feb 2019 at 10:39, Gerard Rowe <GerardR@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@ks.uiuc.edu <owner-namd-l@ks.uiuc.edu> on behalf of Francesco Pietra <chiendarret@gmail.com>
Sent: Thursday, February 14, 2019 9:46 AM
To: Eric Smoll; melomcr@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@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@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@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.