Constrained Optimization : statpt ?

[brijesh]

Dear All,
I am using TURBOMOLE V6.3.1.  For constrained optimization  at RI-BLYP-D3/def2-SVP) should I use
jobex -ri -c 100
or
jobex -statpt -ri -c 100

?

Thank you
best regards
Brijesh

[antti_karttunen]

Hi,

for 6.3.1, statpt was already the default so you can use jobex -ri -c 100

Antti

[brijesh]

Dear Antti,
I am trying to perform constrained-optimization for a large system. After define when I run "ired" It gives me following error:

ndi30 too small

What does that mean and how to fix it ?

If I skip this step I am able to perform the optimization using the cartesian coordinates. But then I am not able to use SMP or MPI and the jobs becomes very slow using 1 CPU.

Thank you very much in anticipation.
best regards
Brijesh

[antti_karttunen]

Hi,

Turbomole has some static parameters that have been fixed during the compilation. It seems that your system is so big that define hits the ndi30 limit. You could ask your system administrator to obtain the "huge" version of Turbomole, where many limits have been doubled in comparison to the normal version. If this does not help, you (or the administrator) should contact Turbomole support.

Structural optimization in cartesian coordinates should run perfectly fine with SMP/MPI, though. So, something else is wrong here.

Antti

[uwe]

Hello,

ndi30 too small: Either you have several fragments which are all quite far away from each other, or many atoms are very (unreasonably) close to each other, so that the number of next neighbors explodes.

Check your geometry and see if it looks reasonable. If it does, then you have fragments far away from each other. In this case the generation of internal redundant coordinates might fail, because the distances are too large to be considered as bonds. The solution here could be to define bond between the fragments by hand first and then call ired again:

• identify the atoms which you want to (artificially) connect to each other
• add a keyword $user-defined bonds to the control file (or to coord and set $user-defined bonds file=coord) with entries:
  
  $user-defined bonds
      1 -   13,     2 -   14,     3 -   15
  
  this connects atom 1 with 13, 2 with 14, etc.
   
• retry ired. If that fails again, modify the list of user-defined bonds. Do not define too many to avoid linear dependencies, but a sufficiently large number (taking the degrees of freedom into account).

Using internal redundant coordinates or Cartesian ones has no influence on the serial or parallel version. The parallel energy and gradient steps of an optimization know nothing about the internal coordinates, so the inability to run the job in parallel must have other reasons.

Regards,

Uwe

[brijesh]

Dear Uwe and Antti,
Thanks for your detailed reply. I have several fragments and they are kind of far away from each other (I guess no two atoms are too close).
Therefore the easiest thing would be to optimize the complex with cartesian coordinates with nearly 50% of the atoms frozen (with SMP or MPI).

I am using RI-BLYP-D3 with def2-SVP basis set (nearly 300 atoms). I tried to run with MPI and the GEO_OPT_FAILED file gives following info:


ERROR: your energy calculation did not converge !!
       Possible reasons:
       - not enough iterations: increase the max. number of SCF iterations
         i.e. $scfiterlimit
         and check your occupation.
       - because of wrong input like starting an RI calculation
         without having switched on RI
       - missing input (basis set, auxiliary basis set, MOs, ..)
    Check job.last and job.<number> for more detailed error output


job.last file gives following message :

DIRECT SCF FAILED TO CONVERGE => jobex quits

Should I increase SCF iteration limit (to 100) ?

Thanks.
best regards
Brijesh

[antti_karttunen]

Hi,

In addition to increasing the iteration limit, it always makes sense to tune few other SCF settings, too. For example:

  $scfdamp start=1.500 step=0.100 min=0.500
  $scforbitalshift automatic=.2
  $scfiterlimit 100


These are still pretty "mild" settings, so please see manual and the FAQ section of the forum for more details.

Best,
Antti

[antti_karttunen]

I forgot to mention, please also keep an eye on the orbital occupations with the eiger tool, if the system is bit unusual (especially if there is any symmetry around). The fermi keyword can be helpful if you have problems with the occupations.

Antti

[brijesh]

Dear Antti,
I followed your suggestion and submitted two jobs, one with MPI and the other one with SMP. The job with MPI is still running while the job with SMP quickly  gave following error:

job.1 file:

OPTIMIZATION CYCLE 1
Tue May 28 15:20:16 CEST 2013
Parallel program rdgrad_mpi will be taken out of the TURBODIR directory.
STARTING rdgrad ON 32 PROCESSORS!
RUNNING PROGRAM /lap/turbomole/6.3.1/bin/em64t-unknown-linux-gnu_ga/rdgrad_mpi.
PLEASE WAIT UNTIL rdgrad HAS FINISHED.
Look for the output in slave1.output.
 <<<<<<<<<<<<<<< OUTPUT FROM PROCESS                      0 >>>>>>>>>>>>>>>
 distribution of control by ridft_mpi/rdgrad_mpi
 operating system is UNIX !
 hostname is         t-cn0330.hpc2n.umu.se

 data group $actual step is not empty
 due to the abend of ridft


 check reason for abend ...

 use the command  'actual -r'  to get rid of that

 quit: process                      0  failing ...
 MODTRACE: no modules on stack

  CONTRL dead = actual step
 rdgrad ended abnormally
error in gradient step (1)



any suggestion? Thanks

best regards
Brijesh

[antti_karttunen]

Hi,

The message

data group $actual step is not empty
due to the abend of ridft

means that it was ridft that crashed. Please check what ridft says in the end of job.last. But anyway if the MPI version is running OK, I would use it. The "SMP" version of ridft/rdgrad is just another MPI implementation using global arrays. Some features like parallel hybrid functionals have been only implemented in the GA version, but for standard RI-BLYP-D3/def2-SVP the "classic" MPI works just fine. The GA version might require some additional tuning of memory settings for large systems, please see http://www.cosmologic.de/data/DOK_HTML/node31.html (it could be that ridft crashed due to these issues).

Actually, from the documentation of the forthcoming version 6.5 it seems that there will be another type of SMP implementation of ridft/rdgrad in the future: http://www.cosmologic.de/data/DOK_HTML/node30.html
I think this is good news, since the "fork"-parallel aoforce, escf, and egrad have worked really well.

Antti

[uwe]

Hello,

Therefore the easiest thing would be to optimize the complex with cartesian coordinates with nearly 50% of the atoms frozen (with SMP or MPI).

fixing atoms does not necessarily mean that the optimization converges faster. As an example try to fix all heavy (non-hydrogen) atoms to optimize just the Hs - this will usually not be faster than letting the optimizer do its work without any constraints. Because it can use the information given by the gradients on the Hs and the rest to guess a reasonable new structure for the next step. But if you can fix whole fragments which are only weakly bound to other fragments, it might indeed help.

Regards,

Uwe

[brijesh]

Dear Uwe and Antti,
Thank you.
I will try to fix the whole fragment and then perform constrained-optimization. Since these fragments were taken from the protein structure, full optimization may lead to very different structures which I would not want.
I have a small doubt: in case I fix all the whole fragments (using x, y ,z coordinates) it is same as single point calculation, isn't it?

best regards
Brijesh