[Pw_forum] Installing QE 4.0.5 on Mac Pro

[Axel Kohlmeyer]

On Tue, May 26, 2009 at 12:15 PM, Cristian Degli Esposti Boschi
<cristian.degliesposti at unibo.it> wrote:
> Therefore I pass the option "--disable-parallel" to configure and make
> all (using gfortran). I tried both pw.x and cp.x with two input files
> for a rather demanding system; on a 2 Xeon Quad-core machine with 16 GB
> RAM very similar to the Mac Pro they are successfully processed while
> on the Mac Pro I get:
>
>
> pw.x(45534) malloc: *** mmap(size=1093816320) failed (error code=12)
> *** error: can't allocate region
> *** set a breakpoint in malloc_error_break to debug
> Operating system error: Cannot allocate memory
> Out of memory

well, your operating system tells you that you are running out
of memory. this is not the fault of Q-E.

perhaps the problem is too big for the machine?

> or
>
> cp.x(45549) malloc: *** mmap(size=546910208) failed (error code=12)
> *** error: can't allocate region
> *** set a breakpoint in malloc_error_break to debug
> Operating system error: Cannot allocate memory
> Out of memory
>
>
> One thing I noticed in the file config.log is that there
> is no malloc usability. The file malloc.h is not found, so
> I made a symlink from /usr/include/malloc/malloc.h to
> /usr/include/malloc.h. But then the same problem happens
> with "struct mallinfo.arena"...

this is nonsense. malloc.h is an optional header.
it does not have to be there. never mess with
system headers. all hell can break lose.

>
> Is there a special variable to pass to locate correctly
> the (malloc related) include files under OSX Leopard 10.5, maybe when I
> use the compilers from FINK?
>
>
> Finally, what I meant about 64-bit compiling is that I used to get
> similar errors with a C++ code of mine:
>
> dmrgcc(45305) malloc: *** mmap(size=487424) failed (error code=12)
> *** error: can't allocate region
> *** set a breakpoint in malloc_error_break to debug
> terminate called after throwing an instance of 'std::bad_alloc'
>   what():  St9bad_alloc

well, same thing. you are running out of memory.

> In that case I solved the problem by passing explicitely the
> option "-m64" to the compilers; with Quantum Espresso the configure step
> with -m64 is ok, but when I make all I get several errors in fft_scalar.

ok. now that explains something. your default compiler installation
is a 32-bit version. those have a limited address space of about
2GB. this is why you are running out of memory. when you change
to 64-bit mode, this is resolved. however, you cannot just change
make.sys. you have to re-run configure and pass the -m64 flag
with the compiler flags (for c, f77 _and_ f90) and then compilation
should work. in 64-bit mode some parts of the fortran and c code
in Q-E have to be adjusted due to the difference in pointer size
vs. the default integer size compared to 32-bit mode.

cheers,\
     axel.

>
> Thanks for your time. Cristian
> --
> ___________________________________________________
> Cristian Degli Esposti Boschi
> CNR, CNISM, Unita' di Ricerca di Bologna, c/o
> Dipartimento di Fisica, Universita' di Bologna
> viale Berti-Pichat, 6/2, 40127, Bologna, Italia
> tel. ++39 051 2095114   fax ++39 051 2095113
> e-mail: cristian.degliesposti -AT- unibo.it
> web:    http://www.df.unibo.it/fismat/theory
> ___________________________________________________
>
> _______________________________________________
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://www.democritos.it/mailman/listinfo/pw_forum
>
>



-- 
=======================================================================
Axel Kohlmeyer   akohlmey at cmm.chem.upenn.edu   http://www.cmm.upenn.edu
  Center for Molecular Modeling   --   University of Pennsylvania
Department of Chemistry, 231 S.34th Street, Philadelphia, PA 19104-6323
tel: 1-215-898-1582,  fax: 1-215-573-6233,  office-tel: 1-215-898-5425
=======================================================================
If you make something idiot-proof, the universe creates a better idiot.