Alberto,
Although writewave itself doesn't take long and it is not necessary to be
parallel, siesta needs to do at least one SCF computation from the calculated
.DM files of a converged parallel run. For large systems, the memory usage is
so big that serial code can not finish that single SCF run
e...
>
> sergey
>
> -- Forwarded message --
> From: Cherry Y. Yates <[EMAIL PROTECTED]>
> Date: Thu, 07 Jun 2007 21:27:16 GMT
> Subject: Re: [SIESTA-L] writing the wavefunction
> To: SIESTA-L@listserv.uam.es
>
>
>
>
>
> 07.06.07, 21
Dear Alberto,
Thanks, but the fix doesn't work. I downloaded it and replaced the old version.
Recompiled. But it did the same as the previous one -- exit without any errors
after writing these lines:
* Maximum dynamic memory allocated = 1403 MB
coxmol: Writing XMOL coordinates into file tnw.xyz
There is indeed a bug in the parallel operation of writewave.F. Please go to
http://fisica.ehu.es/ag/siesta-extra/issues.html
to download an interim fix.
Regards,
Alberto
On 6/6/07, Cherry Y. Yates <[EMAIL PROTECTED]> wrote:
Sergey,
Let's get the bottom of this. My mac
Sergey,
Let's get the bottom of this. My machine is Intel(R) Xeon(TM) CPU 3.60GHz. I
found the initial setting of the stack size is 10240 kb. When I set the stack
size to unlimited, it did make the sequential ifort code as fast as the pgi
one, and it can generate the wavefunction. The previous err
Cherry,
Interesting. What kind of machine do you use? x86 (32 bit) or x86_64? And what
kind of error message you get with ifort compiler and your big system? If it is
a "segmentation fault", then my guess - it could be a memory problem for array
allocation. Usually compiler option "-mcmodel=me
Dear Sergey,
This is the output of the ulimit:
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
file size (blocks, -f) unlimited
pending signals (-i) 1024
max locked memory (kbytes, -l) 32
max memory size (kbytes, -m)
Dear Sergey,
I ckecked the command ulimit, and it outputs "unlimited". It looks like not the
stack issue. Any further suggestions? Thanks,
Cherry
--- Sergey Lisenkov <[EMAIL PROTECTED]> wrote:
> Cherry,
>
> It is well known now that intel compiler uses a very small stack space. So,
> probably
Cherry,
It is well known now that intel compiler uses a very small stack space. So,
probably you might be running out of stack space. Check your settings with
command: "ulimit". If you don't have an output of that command - 'unlimited',
you'll have to enlarge the stack space user limit. The de
Dear Sergey,
I used the ifort compiler. What is "ulimit"? I grep all the output files and
the source codes, but didn't find anything called "ulimit"...
By the way, I found an interesting timing of the serial version of SIESTA
compiled by ifort comparing with that compiled by pgf90. Both are using
Cherry,
What kind of fortran compiler doesn't work for you? What is an output from
'ulimit' ?
sergey
06.06.07, 03:41, Cherry Y. Yates <[EMAIL PROTECTED]>:
> And it looks like it is not related to acml. I compiled an acml library by
> ifort, and link to it instead of lapack (or linalg.a). But
And it looks like it is not related to acml. I compiled an acml library by
ifort, and link to it instead of lapack (or linalg.a). But it still CANNOT
generate .WFS files for large systems; while a PGI pgf90 compiled SIESTA can do
the job. I hope some developers can fix this bug.
Cherry
--- "Cherr
Dear SIESTA developers,
I found a very wired issue of SIESTA. I compiled BLAS and LAPACK (or use
linalg.a) for the lapack and blas. It can write .WFS functions for small
systems(< ~ 1000 orbitals), but for large systems (such as ~ 3000 orbitals), it
cannot wite the wavefunctions anymore! I have th
13 matches
Mail list logo
