error in mpi
 

Hi,

I have installed a code under mpich, blas, blacks, lapack and scalapack. The code itself is running with no problem. But one of its utilities is giving me the following error while I want to "make" it:

Is there any way to solve this problem?

Dear sryzdn:
May be it is an undefined type.
Try to grep for `__mpi__r8_v_MOD_mpi_reduce_t' and send the results to a file.
May be you find a header file that is not in the path. (Which defines the type)
Also you can try to guess the type yourself. (But you have to see the source)
If you've got many errors lkike this it is probably you lack a header file.

Regards.

Alejandro.

Dear Alejandro,

Thanks for the reply.

The code I have compiled, works under mpich2, lapack,blas, scalapack and blacks. The code itself has no problem in parallel execution, only this utility cannot be "made" and the complete error list I receive is as enclosed.

Please let me know what header file should be changed?

http://icmab.cat/leem/siesta/CodeAcc...downloads.html
> Siesta 3.2 > http://icmab.cat/leem/siesta/CodeAcc...siesta-3.2.tgz
cd siesta-3.2/Obj/ && sh ../Src/obj_setup.sh && ../Src/configure && make : OK.

cd ../Util/Gen-basis/ && make : No errors. The executable etc. created OK.

? What is "siesta-TEST-3.2" ?

-

Hi,

I have installed siesta in parallel in Packages directory and since two days ago I have this trouble with Gen-Basis, I just decided to do whatever I want on a TEST siesta.
The errors I get above are the ones that sow themselves during the parallel installation of siesta.

Here is the error I get by following your suggestion exactly:

why should it ask for dc lapack in serial form?!?!?

? May be you didn't create 'dc_lapack.a' ? Or it's in a wrong location ?

$ cd siesta-3.2/
$ find . -name dc_lapack.a : The reply is : ./Obj/dc_lapack.a

$ locate liblapack.a : Reply : /usr/lib/liblapack.a

$ locate libblas.a : /usr/lib/libblas.a

-

I have the said libraries in different places:

$ find . -name dc_lapack.a
$ locate liblapack.a
$ locate libblas.a

Which OS are you using ?
$ cat /etc/*release* <Enter>
$ uname -m <Enter>

I didn't manage to make a setup that will fail ..
$ cd siesta-3.2/Util/Gen-basis/ && make : OK.
$ cd renamed-siesta-3.2/Util/Gen-basis/ && make : OK.

Why are you building the internal libblas.a / liblapack.a ?

-

I did everything from scratch today. I installed mpich, lapack, blas and ... again and tested them all for their correct installation (I also again downloaded them from netlib and the relevant links)
It did not change anything in parallel siesta and again I received those "undefined references" !!!!~~~~
But in the siesta serial installation I just made a link of the said libraries in Gen-basis directory and it was made finally ~~~

Now back to your questions:

fedora 19
Fedora release 19 (Schrödinger’s Cat)
NAME=Fedora
VERSION="19 (Schrödinger’s Cat)"
ID=fedora
VERSION_ID=19
PRETTY_NAME="Fedora 19 (Schrödinger’s Cat)"
ANSI_COLOR="0;34"
CPE_NAME="cpe:/o:fedoraproject:fedora:19"
Fedora release 19 (Schrödinger’s Cat)
Fedora release 19 (Schrödinger’s Cat)
cpe:/o:fedoraproject:fedora:19
x86_64

I don't know how to build them externally. I just follow the installation guide. Please tell me how to do it.

By the way, I also tried to make an FC_SERIAL symbol (f95 or gfortran) in the arch.make so that gen-basis can compile with serial compiler. Didn't work out in parallel siesta.

# 9 : Fedora 19 - x86_64.
You don't :
libblas.a, liblapack.a can be installed with #yum install blas-static lapack-static
.. But they were not asked for, when making Gen-basis on Fedora :

# yum install \
blacs-mpich2-devel.x86_64 scalapack-mpich2-devel.x86_64 mpich2-devel.x86_64 lapack-devel.x86_64

$ cd siesta-3.2/Obj/ && sh ../Src/obj_setup.sh && ../Src/configure && make
$ cd ../Util/Gen-basis/ && make : No errors.

Thank you, I just did not use "yum" to install them, but linking them in the serial installation helped and I ran it.
But still it bothers me that I could not make it in parallel installation. No idea how to get rid of those "undefined references"!!!!

Dear sryzdn:
May be it's not practical, but when I was compiling some module for the emc2, I did something like this:

1) Open the files alloc.F90 and xcmod.F and see if there are some common headers.
If there are, there should be the: "typedef sometype __mpi__integer_s_MOD_mpi_bcast_t".

If you could guess the type, could give it a try. For example, if somewhere says: if __mpi__integer_s_MOD_mpi_bcast_t..., you could guess it is an integer or a boolean...

Then add to the header:
typedef unsigned __mpi__integer_s_MOD_mpi_bcast_t

2)If all this fails, you can do:

grep -rl "__mpi__integer_s_MOD_mpi_bcast_t" $PWD > myfile

Means find every file who has "__mpi__integer_s_MOD_mpi_bcast_t" and send the result to a file. Copy the list by hand if it is not very long.

3) When your balls arrive the floor and the operation is finished, open the file "myfile" and see if there is any header file. And the type definition, obviously.

For example: ../ /myworkingdirectory/placeimpossibletofind/hidden.inc or .h

3) Add it to the include path and try again.

# 11 .
Probably use the Fedora packages. ( Post # 10.)
That would be one way of insuring a package combination,
where the versions are meant to work together.

Which commands are you using for the "parallel builds" ?
I don't think you have show those commands yet ?

-

adelabarra,
Thanks for your reply. I really like to tackle problems I have in linux this way that teaches me even more.
I will test your suggestion and will post the result.

knudfl
Thanks so much for helping me a lot.
Your question:

I just go through the configuration just like what you mentioned, after the "arch.make" is made I edit it as follows and will type "make" Then the mpirun will execute the input files.

adelabarra,

I put some time on your post and found the equivalent for typedef in F90 and could remove the "__mpi__integer_s_MOD_mpi_bcast_t".
I don't know how to remove r8. But I will give it a double try.