TURBOMOLE Users Forum
TURBOMOLE Modules => Ricc2 => Topic started by: jbaltrus on September 25, 2012, 06:36:35 PM
-
Dear all,
I am having similar problem to the reported just below my post with TURBOMOLE 6.3.1
When trying optimization it aborts in gradient step
**************************************************************************
* *
* OPTIMIZATION OF THE GROUND STATE CLUSTER AMPLITUDES *
* *
**************************************************************************
start CC2 from scratch because restart not enabled
Iter. MP2 energy Norm(Omega) Norm(t1) Norm(t2) cpu wall
...........................................................................
error in gradient step (1)
while stderr gives
file name /Users/jbaltrus/machines.6147260
contents
compute-12-316
compute-12-316
compute-12-316
compute-12-316
compute-12-316
compute-12-316
compute-12-316
compute-12-316
compute-12-316
compute-12-316
compute-12-316
compute-12-316
dscf ended normally
dscf ended normally
dscf ended normally
dscf ended normally
dscf ended normally
convgrep will be taken out of the TURBODIR directory
dscf ended normally
dscf ended normally
dscf ended normally
dscf ended normally
dscf ended norma dscf ended normally
dscf ended normally
dscf ended normally
forrtl: severe (71): integer divide by zero
forrtl: severe (71): integer divide by zero
MPI Application rank 4 exited before MPI_Finalize() with status 71
forrtl: error (78): process killed (SIGTERM)
forrtl: error (78): process killed (SIGTERM)
forrtl: error (78): process killed (SIGTERM)
forrtl: error (78): process killed (SIGTERM)
forrtl: error (78): process killed (SIGTERM)
forrtl: error (78): process killed (SIGTERM)
forrtl: error (78): process killed (SIGTERM)
forrtl: error (78): process killed (SIGTERM)
forrtl: error (78): process killed (SIGTERM)
forrtl: error (78): process killed (SIGTERM)
File gradient could not be opened!
Data group $grad not found in file gradient
Job finished at: Tue Sep 25 11:30:42 CDT 2012
Removing job machines file /Users/jbaltrus/machines.6147260
-
come to think of it there is no gradient file in the folder. that's odd. I have
$grad file=gradient
in control files, I have all the rest of files in the folder generated but gradient file is absent
-
even more strange if I run SP ricc2 job it aborts at the same spot
**************************************************************************
* *
* OPTIMIZATION OF THE GROUND STATE CLUSTER AMPLITUDES *
* *
**************************************************************************
start CC2 from scratch because restart not enabled
Iter. MP2 energy Norm(Omega) Norm(t1) Norm(t2) cpu wall
...........................................................................
file name /Users/jbaltrus/machines.6147277
contents
compute-14-385
compute-14-385
compute-14-385
compute-14-385
compute-14-385
compute-14-385
compute-14-385
compute-14-385
compute-14-385
compute-14-385
compute-14-385
compute-14-385
dscf ended normally
dscf ended normally
dscf ended normally
dscf ended normally
forrtl: severe (71): integer divide by zero
forrtl: severe (71): integer divide by zero
MPI Application rank 4 exited before MPI_Finalize() with status 71
forrtl: error (78): process killed (SIGTERM)
forrtl: error (78): process killed (SIGTERM)
forrtl: error (78): process killed (SIGTERM)
forrtl: error (78): process killed (SIGTERM)
forrtl: error (78): process killed (SIGTERM)
forrtl: error (78): process killed (SIGTERM)
forrtl: error (78): process killed (SIGTERM)
forrtl: error (78): process killed (SIGTERM)
forrtl: error (78): process killed (SIGTERM)
forrtl: error (78): process killed (SIGTERM)
Job finished at: Tue Sep 25 11:55:01 CDT 2012
Removing job machines file /Users/jbaltrus/machines.6147277
-
Hi,
whenever a program crashes for unknown reasons, I'd recommend to contact the support.
Typical sources of errors stem from:
- corrupt or incomplete restart files,
- too high memory settings in $maxcor and/or $ricore,
- too low user limits for memory, stack size, shared memory, etc.,
- memory limits are usually re-set by queuing systems themselves, adding ulimit or limit to a script that is submitted to the queue might have no effect.
Regards,
Uwe
-
in general it's all true and well known. I am talking about calculating RICC2/aug-cc-pVQZ CH4 molecule on a system that has been working for several years with TURBOMOLE installed no problem. so ulimit and other things are all behind, not sure why this thin is happening.
What happens at that particular step of ricc2? does it start creating those large scratch files?
-
Hi,
CH4 with symmetry? Perhaps the input is simply too small to run it in parallel on many CPUs?
For CH4 and frozen cores there are only 4 occupied orbitals in C1.
If you have less non-frozen occupied orbitals than CPUs, I am not sure if that will work in all cases. It usually does, though.
Did you also try the SMP instead of the MPI version? I just did MP2 gradients for CH4 with aug-cc-pVQZ on 8 CPUs in C1 and there were no errors.
Regards,
Uwe
-
did MPI with C1 geometry and 1 frozen orbital. Will do SMP right now
-
shockingly it worked, thanks Uwe
-
Hi,
on my systems the MPI version works too for this case. So I can not really say what happened with your job.
Uwe
-
Admins recently have done some heavy lifting of scratch space, I used several definition of TMPDIR, maybe that helped
-
Hi all Turbomole users,
I'm trying to do an optimization (46 atoms, only H and O) with ricc2 module and I got an error in gradient step apparently but which not say others informations :(
the job.0 file give that follows:
reading orbital data $uhfmo_alpha from file alpha .
orbital characterization : scfconv=7
all orbitals will be active in the correlation treatment
reading orbital data $uhfmo_beta from file beta .
orbital characterization : scfconv=7
all orbitals will be active in the correlation treatment
time in RI-CPHF prep cpu: 12.40 sec wall: 13.34 sec ratio: 0.9
error in gradient step
I don't understand cause I already managed ricc2 optimization before and I got this error only after increasing my atoms number,
Can somebody help me?
Thanks in advance,
Cheers,
Sam483