[molpro-user] Building molpro with 8 byte integers?
Manhui Wang
wangm9 at cardiff.ac.uk
Fri Oct 21 14:15:41 BST 2011
Dear Mark,
On 18/10/11 13:08, Mark Dixon wrote:
> Hi,
>
> I'm looking at building molpro in parallel, using Global Arrays on top
> of an MPI library. I'm a little confused on whether/where I should be
> using 8 byte integer libraries and I was hoping someone could help clarify.
>
> I notice that, building molpro on our system, a newish 64-bit RHEL5 box
> with Intel 12.0.2 and associated MKL, "configure" automatically sticks
> an "i8" in the installation path, so I assume it's defaulted to 8 byte
> integers. I assume this is a sensible default.
>
> My dummy questions:
>
> 1) If molpro is building with 8 byte integers, should I be linking it to
> 8 byte integer versions of MKL?
Not always necessary. But if 32-bit BLAS/LAPACK routines are used, it
might cause problems if more than 2 GB of memory is used (these
BLAS/LAPACK routines are called from wrapper routines, which convert 64
to 32-bit integer arguments.).
>
> 2) If molpro is building with 8 byte integers, should I be building GA
> with 8 byte integers?
Yes. The interface between Molpro and GA supposes they use the same size
integers. As a matter of fact, on the same machine both Molpro and GA
always set the same size for Fortran integers by default.
>
> 3) If GA is being built with 8 byte integers, should I be linking it to
> 8 byte integer versions of MKL?
Not necessary. See the manual of Global Arrays: 2.3.3 BLAS and LAPACK
http://www.emsl.pnl.gov/docs/global/um/UG-HTML/GA-UserManual-Main.html#x1-190002.3.1
I think it might have the same problem when converting 64 to 32-bit
integer arguments if number is very big.
>
> Sorry about the simple questions :)
>
> Mark
In a word, it is the best to use the same size integers for all three
programs to avoid any unnecessary problem.
Best wishes,
Manhui
--
-----------
Manhui Wang
School of Chemistry, Cardiff University,
Main Building, Park Place,
Cardiff CF10 3AT, UK
More information about the Molpro-user
mailing list