Dear Serguei and Marcel,

thank you very much for your quick and helpful replies. I should have
mentioned that I had already put MAXMEMORYUSAGE 1000 to the EPR input
and
still had the same problem. By increasing the number to 2000 I was
finally
able to get the program to run. That would ordinarily involve a lot of
swapping if indeed more than 1GB had been used. However, I monitored the
job frequently and found that during the long part (SISF1) the memory
usage kept steady between 37 and 40%. Also, from the timing statistics
(see below) it doesn't look like there was a lot of swap activity or
else
one would expect that total elapsed time were much higher than CPU
time. The difference is less than a factor of 1.5 and can easily be
explained by other CPU intensive processes that were running on the PC
at
the same time. Well, anyway, I will try Serguei's suggestion and tune
the
VECTORLENGTH in the SCF input in case that makes a difference.

Best regards, Alex.

  Timing Statistics

  Total Used : CPU= 125839.85 System=
30.16 Elapsed= 171625.91

  Calls Section ( Mean, Percentage )

------------------------------------------------------------------------
---------------------------
      3 >< ................ 0.00 0.00 0.00
0.03 0.01 0.00
      1 GENPT ................ 41.41 0.03 0.84
2.79 43.19 0.03
      1 PTCOR ................ 37.37 0.03 0.49
1.62 39.72 0.02
      1 POT ................ 979.60 0.78 1.71
5.67 982.45 0.57
      1 SIPREP ................ 0.02 0.00 0.01
0.03 0.03 0.00
      1 EPRPONORMAL TERMINATION
T ................ 1163.88 0.92 0.59 1.96
1165.71 0.68
      1 SISF1 ................ 102715.65 81.62 23.69
78.55 116026.15 67.60
      1 SISUB1 ................ 0.02 0.00 0.00
0.00 0.33 0.00
      1 SICDIA ................ 0.00 0.00 0.00
0.00 1.25 0.00
      1 SICAL ................ 20901.34 16.61 2.82
9.35 53363.69 31.09
      1 SIFIN ................ 0.55 0.00 0.00
0.00 2.74 0.00
      1 SHIFTS ................ 0.01 0.00 0.00
0.00 0.16 0.00
      1 EXIT PROCEDURE ......... 0.00 0.00 0.00
0.00 0.48 0.00

  Currently Open Files (EXIT00)
  ====================

  Unit Access Format Status Type Ident (file)
  -------------------------------------------------------
    3 SEQ FORM TRANSP NORMAL LOGFILE
                                           ( logfile )

  Buffered I/O statistics
  =======================
  Memory available: 8388608
  Number of records fitting in memory: 2028
  Input : 8.3% of 956234 *4k bytes
  Output: 39.3% of 114624 *4k bytes
  Records from serial files evicted: 0
                     others evicted: 106700
  Hash table lookups: 3127018 with 771267 conflicts ( 24.66%)

  Workspace Manager statistics
  ============================
  Allocate : 214
  Delocate : 48
  Relocate : 3
  Extend : 0
  Find : 4
  Available : 0
  Check : 0
  Hide : 4
  Freeze : 3
  Print : 1

  (All arrays delocated)

On Fri, 23 May 2003, Serguei Patchkovskii wrote:

> On Thu, 22 May 2003, Alex Angerhofer wrote:
>> I've tried to calculate the g-tensor of an anion of a chlorophyll
>> derivative (74 atoms, containing Mg, O, N, C, and H). The SCF part
>> runs
>> fine, but EPR aborts with an iraloc error:
>>
>> <May21-2003> <00:06:02> EPR 2002.03 RunTime: May21-2003 00:06:02
>> <May21-2003> <00:06:04> >>>> GENPT
>> <May21-2003> <00:06:04> Acc.Num.Int.= 6.000
>> <May21-2003> <00:06:16> Block Length= 128
>> <May21-2003> <00:06:17> >>>> PTCOR
>> <May21-2003> <00:06:30> >>>> POT
>> <May21-2003> <00:12:21> >>>> SHIFTS
>> <May21-2003> <00:12:21> >>>> SIPREP
>> <May21-2003> <00:12:21> >>>> EPRPOT
>> <May21-2003> <00:19:18> >>>> SISUB1
>> <May21-2003> <00:19:18> >>>> SISF1
>> <May21-2003> <00:19:18> iraloc: exceeded maximum memory
>> <May21-2003> <00:19:18> END
>
> Alex,
>
> Try adding:
>
> VECTORLENGTH 15
>
> to the SCF (not the EPR!) input, and/or:
>
> MAXMEMORYUSAGE 512
>
> to the EPR (not the SCF!) input.
>
> Explanation:
>
> For various reasons, EPR uses the same block length for numerical
> integration,
> as the SCF part. Normally, the SCF part tries to maximize memory
> utilization,
> by choosing the largest vector length possible. Because EPR tends to
> keep somewhat
> more data in memory per numerical integration point, it may run out of
> memory for
> larger systems.
>
>> From the performance point of view, on non-vector platforms there is
>> very little
> benefit in increasing vector length beyond 20-30 (in fact, this may
> even slow the
> things down, by making cache less effective).
>
> Serguei
>
> ---
> Dr. Serguei Patchkovskii
>
> Tel: +1-(613)-990-0945
> Fax: +1-(613)-947-2838
> E-mail: Serguei.Patchkovskii_at_nrc.ca
>
> Coordinator of Modelling Software
> Theory and Computation Group
> Steacie Institute for Molecular Sciences
> National Research Council Canada
> Room 2011, 100 Sussex Drive
> Ottawa, Ontario
> K1A 0R6 Canada
>
>
>
Received on 2003-05-23 15:02:35