Installaton of feap8.4 serial & arpack

[FEAP_Admin]

Did you re-link the code after deleting the file from the archive?  (cd main; make)

[Prof. R.L. Taylor]

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???)

[M. Kurdi]

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.

[Prof. R.L. Taylor]

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.

[FEAP_Admin]

The items in the packages directories must always be build separately.

[M. Kurdi]

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?

[M. Kurdi]

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.

[Prof. R.L. Taylor]

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.

[M. Kurdi]

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.