Compiling with i4 instead of i8 on 64-bit machine


Clicked A Few Times
Hi guys,

Is there any simple, out-of-the-box way to create an i4 build in anyway without tinkering with the tools/GNUMakefile?

I see in the config that USE_INTEGER4 is no longer supported (though still present in the PEIGS Makefile, for reference) and that one can set USE_I4FLAGS. However, this doesn't effect the GA build and so one needs to play with this to get an i4 build of the GA (Or so I presumed - or can I just leave the GA alone?)

The reason I ask is because even if I create a seemingly sensible -i4 build with (adding in --enable-i4 for the GA build) I get spat out just after the geometry is read with:

> s_g_p: ma? 0

which seems to originate from a failed ma_pop_stack in symmetry/sym_geom_prj.F

Any thoughts or suggestions welcomed! As I am stumped.

(In the meantime I shouldl retry building without any alteration of the GA config files, but won't be holding my breath....)

All the best,

Andy

Forum Vet
Andy,
I am not quite sure I fully understood your topic. My main problem is that I do not understand the reason for building with 32-bit integers on a 64-bit architecture ... why do you want to do that?

Thanks, Edo

Clicked A Few Times
Hi Edo,

I want to link the NWChem libraries into another executable, which is 32-bit. And before you ask, yes, I am also trying to port this in the opposite direction to 64-bit but this is also complicated

Therefore, I thought I'd try to build NWChem using 32-bit integers, thinking it should be compatible with this as you give the USE_I4FLAGS option... but this is not as simple as hoped.

For the record, the recipe for v6.1.1 that works for me for the i8 on the Cray XE6:
=
  1. !/bin/bash

  1. Standard options
export NWCHEM_TOP=${PWD}
export NWCHEM_TARGET=LINUX64
export NWCHEM_MODULES=all
export USE_MPI=y
export USE_MPIF=y
export USE_MPIF4=y
export USE_SCALAPACK=y
export USE_64TO32=y
export LIBMPI="."
  1. These need a value else the GA build ignores them
export SCALAPACK_LIB="."
export SCALAPACK_SIZE=4
export LAPACK_LIB="."
export LAPACK_SIZE=4
export BLAS_LIB="."
export BLAS_SIZE=4
  1. Network
export ARMCI_NETWORK=GEMINI
export ONESIDEDED_USE_UDREG=1
export FC=ftn
export CC=cc

module load PrgEnv-pgi
module load onesided

cd src

gmake nwchem_config
gmake 64_to_32
gmake
=

I welcome any suggestions for what I could do to get further towards a working 32-bit build.

All the best,

Andy

Forum Vet
Details about the "other executable"
Sorry to be pedantic, but I am still not sure what you mean by "... another executable, which is 32-bit."
Is this other executable a 64-bit executable that uses 32-bit integers or a 32-bit executable?
By the way, is this effort happening on the Cray XE6 or on a generic LINUX64 platform?
Thanks, Edo

Clicked A Few Times
Hi Edo,

The "other executable" is 64-bit, but uses 32-bit integers by default. It is GULP (http://projects.ivec.org/gulp/).

GULP can be compiled with 64-bit integers, but this results in alot of errors on initiation at runtime, which I am going through at present. The inverse if you like of NWChem, which I am trying to take down to 32-bit integers.

At present NWChem presents this seemingly inoccuous error in the symmetry module at runtime, and though it compiles OK I'm confident it is due to changing from 64 to 32 bit integers as this is the only alteration I have made.

And yes, this is all being done on the Cray XE6. For the calculations we want to do, it's really the only suitable machine I have access to.

Should I presume there is no easy solution to the question I have posed given by the indirectness of your response?

All the best,


Andy

Forum Vet
Andy,
I think that the only viable solution is to get a 64-bit binary of Gulp. I do not see any way to get 32bit executable of NWChem
ob the Cray XE6 because of all the library dependencies.

Cheers, Edo

Clicked A Few Times
Hi Edo,

Sorry I just edited my post as I hadn't written it correctly. It is a 64-bit binary with 32-bit integers.

So the question remains can how would one build NWChem with 32-bit integers, if it were to be feasible?

Andy

Forum Vet
Quote:Logsdail Jan 18th 3:55 pm
Hi Edo,

Sorry I just edited my post as I hadn't written it correctly. It is a 64-bit binary with 32-bit integers.

So the question remains can how would one build NWChem with 32-bit integers, if it were to be feasible?

Andy


That's still something that might need a bit of work and a slightly more likely to be a viable option,
but it is not guaranteed to be successful.
Anyhow, my question (another one ...) is: why do you need a tightly couple interface Gulp/NWChem?
I am assuming you are going to build one monolithic binary, right?
What about a more loosely coupled interface that does not require to worry about the size of integers?

Cheers, Edo

Clicked A Few Times
Quote:Edoapra Jan 18th 4:03 pm


What about a more loosely coupled interface that does not require to worry about the size of integers?



I have a harness in the middle, if that is what you mean. I am not directly linking them into each other.

Quote:Edoapra Jan 18th 4:03 pm


What about a more loosely coupled interface that does not require to worry about the size of integers?



What do you mean by a loosely coupled interface?


Whilst this goes on, I am still none the wiser about compiling NWChem with 32-bit integers! Could you perhaps explain to me what kind of problems I might be encountering with this, if we can't directly attack the problem in hand with a solution?


Forum >> NWChem's corner >> Compiling NWChem