FEAP User Forum
FEAP => Installation => Topic started by: damir on July 16, 2013, 09:06:51 AM
-
Dear experienced users,
I successfully compiled FEAP 8.4 and ARPACK (serial option) but after using 'arpa' in, say, Ieuler2 example FEAP reported that
no procedure or command named arpa exists. As an relativelly unexperienced user of makefile I obviously missed something trivial. Of course, serial FEAP8.4 alone works just fine.
Please help.
--> Feap Archive updated <--
(cd main; make feap)
make[1]: Entering directory `/home/damir/feap84/ver84/main'
gfortran -c -O3 -ftree-vectorize -Wall -I/home/damir/feap84/ver84/include -I/home/damir/feap84/ver84/include/integer4 feap84.f -o feap84.o
ranlib /home/damir/feap84/ver84/Feap8_4a.a
gfortran -o feap feap84.o /home/damir/feap84/ver84/packages/arpack/archive/archivelib.a /home/damir/feap84/ver84/packages/arpack/arpacklib.a \
/home/damir/feap84/ver84/packages/blas/blaslib.a /home/damir/feap84/ver84/packages/lapack/lapacklib.a /home/damir/feap84/ver84/Feap8_4a.a -L/usr/lib/i386-linux-gnu -lX11 -lm
make[1]: Leaving directory `/home/damir/feap84/ver84/main'
--> Feap executable made <--
Regards,
Damir
-
What you have looks ok. I have attached a file for you to try. It should make a plot of the first 4 eigenmodes of a beam (using arpack as the eigensolver).
If it does not and the error message is what you note ("no proceedure"), then it means that during your build of arpacklib.a something went wrong. The procedure ARPAck is programmed as a 'user macro' in the file umacr10.f in the directory $(FEAPHOME8_4)/packages/arpack.
If you type 'ar tv arpacklib.a' you should see it in the archive.
Here is what I see:
% ar tv arpacklib.a
rw-r--r-- 501/20 12848 Jul 15 10:15 2013 arfeaps.o
rw-r--r-- 501/20 6272 Jul 15 10:15 2013 aropk.o
rw-r--r-- 501/20 3552 Jul 15 10:15 2013 aropm.o
rw-r--r-- 501/20 2112 Jul 15 10:15 2013 pamult.o
rw-r--r-- 501/20 3696 Jul 15 10:15 2013 primul.o
rw-r--r-- 501/20 16464 Jul 15 10:15 2013 umacr10.o
-
Dear FEAP Admin,
thanks for helping me. I'm obviously not totally wrong. Actually, 'ar tv' is practically identical and obtained
using 'make install' inside /feap84/ver84/packages/arpack (is it maybe wrong?):
damir@damir-hp:~/feap84/ver84/packages/arpack$ ar tv arpacklib.a
rw-rw-r-- 1000/1000 7624 Jul 16 17:16 2013 arfeaps.o
rw-rw-r-- 1000/1000 2548 Jul 16 17:16 2013 aropk.o
rw-rw-r-- 1000/1000 1516 Jul 16 17:16 2013 aropm.o
rw-rw-r-- 1000/1000 1136 Jul 16 17:16 2013 pamult.o
rw-rw-r-- 1000/1000 1856 Jul 16 17:16 2013 primul.o
rw-rw-r-- 1000/1000 8824 Jul 16 17:16 2013 umacr10.o
damir@damir-hp:~/feap84/ver84/packages/arpack$
but 'arpa' is not recognized even in Your test file Ieig1. Output on the screen is the same
(no procedure or command exists). Additionally, at the end of Oeig1 is always reported:
feap ** Test file for ARPAck **
Solution Commands Variable 1 Variable 2 Variable 3
tang 0.0000E+00 0.0000E+00 0.0000E+00
mass 0.0000E+00 0.0000E+00 0.0000E+00
Inconsistency occurred from PMACIO in data file Ieig1 $
at or near record number 16. Input record is:
arpa,,5
If this record is correct error may result from
missing blank record before new command type.
Regards,
Damir
-
This seems to indicate that you are not getting the umacr10.o from packages/arpack but rather the one from user/ which has been archived in Feap8_4.a.
Can try the following:
1) Edit main/makefile and add ../packages/arpack/umacr10.o after feap.o, i.e.
OBJECTS = feap84.o ../packages/arpack/umacr10.o
2) type make to rebuild the executable
3) try to run the problem again
-
Dear FEAP_Admin,
as You noticed, it seems that arpacklib.a is not properly built. Here is the output according
to Your last suggestion:
damir@ubuntu4:~/feap84/ver84/main$ make
gfortran -c -O3 -ftree-vectorize -Wall -I/home/damir/feap84/ver84/include -I/home/damir/feap84/ver84/include/integer8 ../packages/arpack/umacr10.f -o ../packages/arpack/umacr10.o
ranlib /home/damir/feap84/ver84/Feap8_4a.a
gfortran -o feap feap84.o ../packages/arpack/umacr10.o /home/damir/feap84/ver84/packages/arpack/archive/archivelib.a /home/damir/feap84/ver84/packages/arpack/arpacklib.a \
/home/damir/feap84/ver84/packages/blas/blaslib.a /home/damir/feap84/ver84/packages/lapack/lapacklib.a /home/damir/feap84/ver84/Feap8_4a.a -L/usr/lib/i386-linux-gnu/ -lX11 -lm
/home/damir/feap84/ver84/packages/arpack/arpacklib.a(arfeaps.o): In function `arfeaps_':
arfeaps.f:(.text+0x174): undefined reference to `dsaupd_'
arfeaps.f:(.text+0x393): undefined reference to `dseupd_'
collect2: ld returned 1 exit status
Regards,
Damir
-
There is something wrong with your loader/linker. It is not following the 'usual' rules.
Perhaps you can try a different compiler (ifort/icc) or rebuild your GNU compiler compilation.
-
Hello,
I would like to use the arpack package. To install I uncommented the two statements in the makefile.in corresponding to arpack packgage. Then I execute make install. I am getting same error as the one mentioned above.
# arpack archive library
ARCHIVELIB = $(FEAPHOME8_4)/packages/arpack/archive/archivelib.a
# parpack library
ARPACKLIB = $(FEAPHOME8_4)/packages/arpack/arpacklib.a
I tried the recommendation above of including umacr10.o explicitly in the makefile of main directory but I get same error above:
/FEAP/feap4/ver84/packages/arpack/arpacklib.a(arfeaps.o): In function `arfeaps':
/FEAP/feap4/ver84/packages/arpack/arfeaps.f:142: undefined reference to `dsaupd_'
/FEAP/feap4/ver84/packages/arpack/arfeaps.f:250: undefined reference to `dseupd_'
It seems the inclusion of umacr10.o worked but one has to include objects of other files. I also tried to rename the macro to number 19 as number 10 is used for other purpose. But it still seems to execute the dummy macro and not the arpack macro. I am not sure what would direct feap to execute the one in the arpack directory and not the user directory?
I also ran the make install in the arpack and archive directories explicitly to build the archive but without success.
I am running on a cluster. If you would please recommend what I can relay to my IT support to check. Thanks.
-
Something in your loader is not working. We do not have an Ubuntu system so it is hard to say what it going on.
You can try putting the relevant object files
directly on the build line in main/makefile and skip the arpack achive files.
-
My system is red hat Linux. But you are right that this occurs on different systems. Thanks for the recommendation.
-
We have Redhat (Fedora as well as CentOS) and do not see this issue. Not sure what to tell you.
-
I tried make clean, then make install but with ifort compiler. But this does not resolve the issue. Still when running through gdb umacr19 opens from the user directory and not from the arpack directory.
-
Maybe the best thing to do is to cut your losses and to simply remove the dummy user macro file from the FEAP8_4.a archive (use ar dv ...; don't forget to also run ranlib on the archive).
-
Thanks for recommending. Can you elaborate on what exactly one should do? I tried the following on Feap8_4a.a archive but still get same error:
ar -dv umacr19.o
ranlib Feap8_4a.a
However, it would be nice to use the facility in place. As I would like to archive several macros I was working on by generating a package (similar to arpack) . This would free up the user macros.
I see that the implementation only uses symmetric option. Is there a non-symmetric option as well?
-
ar -dv Feap8_4a.a umacr19.o
ranlib Feap8_4a.a
should remove the dummy file.
Not sure about your other question you will have to read up on arpack and look at the implemented interface.
-
Sorry I miswrote. I typed exactly what you suggested. The user umacr19.o is deleted from the archive but when running the program it still picks up the user umacr19.o.
In rerunning ar -dv Feap8_4a.a umacr19.o it indicated that umacr19.o is not a member of the archive.
I should say that umacr19.o is not strictly dummy as it has been programmed.
I'm planning an install of FEAP on my workstation and I'm hoping this issue would disappear.
-
Did you re-link the code after deleting the file from the archive? (cd main; make)
-
When you changed umacr10.f to umacr19.f did you change t he name of thesubroutine inside to umacr19 and also the definition of 'ma10' to 'ma19'? You need all these changes. Then reload umacr19.f ( you should be able to leave it in the archive too???)
-
The linking error is attached.
I know that umacr19.o is a member of the arpacklib.a archive but this is not picked up.
The issue seems that the "make" utility is not working properly with what is in the arpack directory. For example if one does "/ver84/make clean" then "/ver84/make install" from I notice that the arpack archive never gets built like it is supposed to. The only way to build it is if I go in the directory and execute make. I tried to install on a Mac work station and the archives never get built as well.
Yes I changed name of subroutine and the definition of the macro. Thanks for checking.
-
Eigenvalues for unsymmetric matrices require complex arithmetic. Feap has some complex arithmetic but the eigen problem is not coded for any complex forms. If not too big maybe port to matlab.
-
The items in the packages directories must always be build separately.
-
I am thinking of perhaps adding the non-symmetric option to arpack package as I think it is available in original arpack. Porting to matlab is an option I was trying to avoid.
Is there a reason why the user macro is not picked up from arpack archive even when it is available there?
-
I was able to install on a Mac machine. I used gfortran from http://gcc.gnu.org/wiki/GFortranBinaries#MacOS
The arpack library runs with no error or any changes to the makefile files. Unfortunately I am unable to advise anyone resolving error but to install a different compiler.
-
Are you sure that one of the files does not have the name 'umacr19'? For example if you moved 'umacr19.f' to 'umacr10.f' then the name of the routine is still 'subroutine umacr19(....' in the umacr10.f file.
-
No sir this really not the issue here. The problem is that the macro in the archive or the whole archive in general of arpack didn't link correctly.
On the new machine when I had user umacr19 defined as not dummy the compiler complained that there are two conflicting object files ( with arpack umacr19) only after I commented the command name definition in the user macro that I was able to link umacr19.o.