Installing Fortran library Expokit (Windows/Ubuntu) - fortran

I am looking to perform matrix exponentials, which apparently the Expokit library is suitable for. Sadly unlike Lapack or OpenMP this is not easily installed from Cygwin or Mingw for Windows. Therefore I have downloaded the library from here, however once unpacked it consists purely of .f files with little guidance on how to use them. The only site I've found online isn't much use (Fortran Wiki), as it doesn't give any indication of how the Expokit library is linked.
I would greatly appreciate any guidance on how to install Expokit on Windows, or alternatively on Ubuntu if Windows is not suitable.
Making the change suggested by ripero and running 'make sample_d' on Ubuntu I get the log shown below. I assume this means the sample has been compiled successfully, but I have no idea how this enables me to use Expokit as a library in my Fortran programs. Could someone please provide guidance on this?
XX:~/programs/expokit/expokit/fortran$ make sample_d
f77 -O3 -c blas.f
blas.f:404:72:
10 assign 30 to next
1
Warning: Deleted feature: ASSIGN statement at (1)
blas.f:409:19:
20 go to next,(30, 50, 70, 110)
1
Warning: Deleted feature: Assigned GOTO statement at (1)
blas.f:411:72:
assign 50 to next
1
Warning: Deleted feature: ASSIGN statement at (1)
blas.f:420:72:
assign 70 to next
1
Warning: Deleted feature: ASSIGN statement at (1)
blas.f:427:72:
assign 110 to next
1
Warning: Deleted feature: ASSIGN statement at (1)
blas.f:1621:72:
10 assign 30 to next
1
Warning: Deleted feature: ASSIGN statement at (1)
blas.f:1628:19:
go to next,(30, 50, 70, 90, 110)
1
Warning: Deleted feature: Assigned GOTO statement at (1)
blas.f:1630:72:
assign 50 to next
1
Warning: Deleted feature: ASSIGN statement at (1)
blas.f:1639:72:
assign 70 to next
1
Warning: Deleted feature: ASSIGN statement at (1)
blas.f:1644:72:
100 assign 110 to next
1
Warning: Deleted feature: ASSIGN statement at (1)
blas.f:1671:72:
85 assign 90 to next
1
Warning: Deleted feature: ASSIGN statement at (1)
blas.f:1689:16:
go to next,( 50, 70, 90, 110 )
1
Warning: Deleted feature: Assigned GOTO statement at (1)
f77 -O3 -c lapack.f
f77 -o sample_d sample_d.o clock.o expokit.o mataid.o blas.o lapack.o

Your Fortran compiler fails to compile file sample_d.f due to a non-standard format statement. The source code of the same file provides instructions for how to fix it if this happens:
9001 format( <mprint>(1X,D11.4) )
*--- Some compliers (e.g., g77) generate 'Unsupported FORMAT specifier'
* with the specification above. In this case, simply use this form:
* 9001 format( 5(1X,D11.4) )
If you comment the first line above (add a * as the first character of the line) and uncomment the last line (remove the leading *), the error should disappear.
I don't think there is a particular significance to running make sample_d other than ensuring that the object files are created and that a sample program can be compiled and linked against them in order to create a working binary.
First, you should be aware that you have compiled Expokit and one of the sample programs using what their Makefile calls case 3, where the required BLAS and LAPACK subroutines are provided by files blas.o and lapack.o, respectively, compiled from their .f counterparts provided by Expokit.
# Among the 3 possibilities below, uncomment the appropriate
# case for your environment and comment the others.
# case 1: works when LAPACK and BLAS are installed.
OBJLIBS =
LIBS = -llapack -lblas
# case 2: works when LAPACK is not installed but BLAS is.
#LIBS = -lblas
#OBJLIBS = lapack.o
# case 3: works when neither LAPACK nor BLAS are installed.
#OBJLIBS = blas.o lapack.o
#LIBS =
If your system already has BLAS and LAPACK libraries, they very likely are more optimized than the ones in blas.o and lapack.o, and you probably will want to change the case in the Makefile (add/remove leading # to comment/uncomment the appropriate definitions of OBJLIBS and LIBS) so that you can use the system BLAS and LAPACK.
In order to use Expokit in your Fortran programs, you need to call from your source code the relevant subroutines (see the Expokit paper and the source code of expokit.f and mataid.f in order to read about the provided subroutines) and then the simplest is to add to your linking line the following
object files: expokit.o mataid.o followed by all the object files listed in the active OBJLIBS variable in the Expokit Makefile, if any; and
libraries: all the ones listed in the active LIBS variable in the Expokit Makefile, if any.

Related

Linking with LAPACK using gfortran on Fedora Linux

I need some help regarding installation of LAPACK ( for Fortran 95) on a Fedora machine.
I am writing this post after having tried all answers posted to pertinent queries in this forum.
I tried two different options:
METHOD 1
I directly downloaded the lapack95.a library from here (http://www.netlib.org/lapack95/, file named lapack95_linux_redhat.tgz. After unzipping, I could get file lapack95.a
After looking for some answers on how to link and use libraries, I wrote a trial code and saved in file try.f90 and then did the following
gfortran -c try.f90
gfortran -o try try.o -L/(name of directory where lapack95.a
was present. I put it in the same directory
as try.f90)/ -llapack95
( The fortran file try.f90 and lapack95.a were in the same directory)
I got the following error:
/usr/bin/ld: cannot find -llapack95
collect2: error: ld returned 1 exit status
I searched on internet and found here (https://forums.fedoraforum.org/archive/index.php/t-248227.html) that we need to install lapack-devel.
I did that and had the same outcome.
Method 2
I also tried running the above command (in Method 1) but without space between / and -llapack95 , i.e. as :
gfortran -o try try.o -L/(name of directory where lapack95.a
was present I put it in the same directory
as try.f90)/-llapack95
and received the following error:
try.o: In function `MAIN__':
try.f90:(.text+0xdb): undefined reference to `sgesv_'
collect2: error: ld returned 1 exit status
Method 3
After having no success, I thought may it's not good idea to use the lapack95.a downloaded directly. I should build it from the original files.
I realized that may be I need to install lapack95 through proper means following which from the same link
http://www.netlib.org/lapack95
I downloaded the file lapack95.tgz and followed the instructions in readme file.( which said just to run make file in SRC)
I made some changes as :
FC1 = f95 -fixed to
FC1 = f95
and
OPTS0 = -u -V -dcfuns -dusty -ieee=full
to
OPTS0 = -u -V
( as suggested on https://www.reddit.com/r/linux4noobs/comments/7tgmb9/fortran_library_netlib_lapack95_installation_error/)
I expected that the library will be created in /usr/lib/ or usr/local/lib as LAPACK3 but couldn't find it.
Infact there was an error ( and thus could not have any .a file )
f95 -free -c -u -V - -I./../lapack95_modules f77_lapack_double.f90 f95: error: -E or -x required when input is from standard input make: *** [../make.inc:45: f77_lapack_double.o] Error 1
I am not sure if any of my method is fine.
I expected Method 1 to work as I am linking the library locally but failure in all 3 cases.
Kindly suggest.
Thanks
Lapack library is a very useful tool to conduct matrix operations in a fast way. On the linux machine, it is very simple to install lapack with the build-in tools: dnf/yum or apt-get [2]. On my Fedora desktop, installation is like this:
sudo dnf install lapack64-devel.x86_64
Here is a small example on how to use lapack lib. The source code is to solve linear equations as linear_eqs.f [3].
Program LinearEquations
c solving the matrix equation A*x=b using LAPACK
Implicit none
c declarations, notice single precision
Real*4 A(3,3), b(3)
integer i, j, pivot(3), ok
c define matrix A
A(1,1)=3.1
A(1,2)=1.3
A(1,3)=-5.7
A(2,1)=1.0
A(2,2)=-6.9
A(2,3)=5.8
A(3,1)=3.4
A(3,2)=7.2
A(3,3)=-8.8
c define vector b, make b a matrix and you can solve multiple
c equations with the same A but different b
b(1)=-1.3
b(2)=-0.1
b(3)=1.8
c find the solution using the LAPACK routine SGESV
call SGESV(3, 1, A, 3, pivot, b, 3, ok)
c
c parameters in the order as they appear in the function call
c order of matrix A, number of right hand sides (b), matrix A,
c leading dimension of A, array that records pivoting,
c result vector b on entry, x on exit, leading dimension of b
c return value
c
c print the vector x
do i=1, 3
write(*,*) b(i)
end do
end
In this code, one lapack function 'sgesv()' is used. To execute this file, run the below command:
gfortran linear_eqs.f -llapack -o lineqs.out
./lineqs.out
The outputs will be:
1.00000024
1.00000036
1.00000036
Reference
[1] https://github.com/fxcoudert/gfortran-for-macOS/releases
[2] BLAS, ATLAS, LAPACK Shared library minimal example
[3] http://physics.oregonstate.edu/~landaur/nacphy/lapack/codes/linear-f.html

llc: unsupported relocation on symbol

Problem
llc is giving me the following error:
LLVM ERROR: unsupported relocation on symbol
Detailed compilation flow
I am implementing an LLVM frontend for a middle-level IR (MIR) of a compiler, and after I convert various methods to many bitcode files, I link them (llvm-link), optimize them (opt), convert them to machine code (llc), make them a shared library (clang for it's linker wrapper), and dynamically load them.
llc step fails for some of the methods that I am compiling!
Step 1: llvm-link: Merge many bitcode files
I may have many functions calling each other, so I llvm-link the different bitcode files that might interact with each other. This step has no issues. Example:
llvm-link function1.bc function2.bc -o lnk.bc
Step 2: opt: Run optimization passes
For now I am using the following:
opt -O3 lnk.bc -o opt.bc
This step proceeds with no issues, but that's the one that CAUSES the problem!
Also, it's necessary because in the future I will need this step to pass extra passes, e.g. loop-unroll
Step 3: llc: Generate machine code (PIC)
I am using the following command:
llc -march=thumb -arm-reserve-r9 -mcpu=cortex-a9 -filetype=obj -relocation-model pic opt.bc -o obj.o
I have kept the arch specific flags I've set just in case they contribute to the issue. I am using Position Independent Code because on next step I will be building a shared object.
This command fails with the error I've written on top of this answer.
Step 4: clang: Generate Shared Object
For the cases that Step 3 fails, this step isn't reached.
If llc succeeds, this step will succeed too!
Additional information
Configuration
The following run on an llvm3.6, which runs on an arm device.
Things I've noticed
If I omit -O3 (or any other level) with the opt step, then llc would work.
If I don't, and instead I omit them from llc, llc would still fail. Which makes me think that opt -O<level> is causing the issue.
If I use llc directly it will work, but I won't be able to run specific passes that opt allows me, so this is not a option for me.
I've faced this issue ONLY with 2 functions that I've compiled so far (from their original MIR), which use loops. The others produce working code!
If I don't use pic model at llc, it can generate obj.o, but then I'll have problems creating an .so from it!
Questions
Why is this happening??!!
Why opt has -relocation-model option? Isn't that supposed to be just an llc thing? I've tried setting this both at opt and llc to pic, but still fails.
I am using clang because it has a wrapper to a linker to get the the .so. Is there a way to do this step with an LLVM tool instead?
First of all, do not use neither llc nor opt. These are developer-side tools that should be never used in any production environment. Instead of this, implement your own proper optimization and codegeneration runtime via LLVM libraries.
As for this particular bug - the thumb codegenerator might contain some bugs. Please reduce the problem and report it. Or don't use Thumb mode at all :)

Compiling DISLIN gfortran

I am having trouble compiling Fortran code with references to DISLIN. I have downloaded DISLIN from the website, unzipped the file and ran the setup. I have added an environment variable called DISLIN (C:\dislin) and added C:\dislin\win to the PATH section of my system variables.
I am trying to compile some example code of the DISLIN website which includes line
USE DISLIN
I am using a MinGW shell to compile with command gfortran -o progrname -ldislin EX11_1.f90 and am getting the following error:
Fatal Error: Cant open module file 'dislin.mod' for reading at (1): No such file or directory.
I have tried changing the variable path and even moving the dislin.mod file (which is there) but still get the same message.
Ok I fixed this problem so thought I come back and post what worked for me incase any one else needs it...
Install both DISLIN and MinGW on the c drive
Copy disgf.a from /c/dislin and dislin.f90 from /c/dislin/gf into the directory containing your fortran files
(for me this is /c/MinGW/pnote)
Using the MinGW shell navigate to you files: cd /c/MinGW/pnote
compile dislin.f90 and your fortran program: gfortran -c dislin.f90 progName.f90 (dislin.f90 obviously only needs to be done once)
link libraries etc and compile: gfortran progName.o disgf.a -luser32 -lgdi32 -lopengl32 -o exeName
'run' exeName
You probably need to specify the path to the DISLIN module files:
gfortran EX11_1.f90 -o progrname -ldislin -I/path/to/DISLIN/modules
and, if not already configured like described here, also the path to the library itself:
gfortran EX11_1.f90 -o progrname -ldislin -I/path/to/DISLIN/modules \
-L/path/to/DISLIN/library
They provide a batch file (windows) to do the compiling and linking for you.
f90link -c My_Program
This is located in c:\dislin\Win
Also, if you are having trouble with the dislin.mod file which resides in c:\dislin\gf then recompile that with the -c compile option. I found all of this info in c:\dislin\readme.inf
near as I can tell (Jan 2018) dislin (64 bit) fails miserably with gfortran 7.2, period; and probably with many other newer compilers.
When trying to link, gfortran 7 says 'dislin.mod' is an unrecognizable format.
I think this program is highly dependent on exactly correct version synchronization - something that renders such software useless imho after many years in research.
and no, the correctness of various 'paths' seems not to help.
after all, gnuplot works, "at all". Not sure why I spent so much time on brand x.
jrc

Causing cpp (C preprocessor) to remove C++ comments on Mac OS X

I have a user report (unfortunately can't verify it due to lack of appropriate machine) that the C preprocessor (cpp) command on Mac OS X 10.6.4 doesn't remove C++/C99 double slash // comments from files it processes, no matter what option it's given. This is the gcc version:
i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5664)
Is it possible to somehow cause it to remove such comments, as one would expect from a C++ preprocessor (this is needed because cpp is used as part of another tool).
I've found a formula that works with the cpp command: try cpp -xc++ (note the lack of spaces between -x and c++).
$ printf '/* block comment */\n// line comment\nnot a comment\n' | cpp -xc++
# 1 "<stdin>"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "<stdin>"
not a comment
contrast:
$ printf '/* block comment */\n// line comment\nnot a comment\n' | cpp -x c++
i686-apple-darwin10-gcc-4.2.1: c: No such file or directory
i686-apple-darwin10-gcc-4.2.1: c++: No such file or directory
i686-apple-darwin10-gcc-4.2.1: warning: '-x -x' after last input file has no effect
i686-apple-darwin10-gcc-4.2.1: no input files
Now '-x c++' is SUPPOSED to work, and DOES work on my Linux box (with gcc 4.4, but I recall it working as long ago as gcc 2.95) so it seems that Apple broke it.
I really must reemphasize the importance of providing a complete, precise test case for questions like these. It did not occur to me yesterday to look for Apple having introduced a bug, because I know that wilx's answer should have worked, and in the absence of a precise description of what the OP's user tried, it was far more likely that they had something else on their actual command line that was negating it. If the command line and error messages I show above were provided in the original question, that would have targeted everyone's attention much more effectively.
Try adding either -x c++ or -x c -std=c99 to the command line.
One partial solution that appears to work is invoke gcc -E instead of cpp.
-E Preprocess only; do not compile, assemble or link
This indeed strips // comments on Mac OS X.
However, I'm still curious why there are problems with cpp itself.

How to start a voice quality PESQ test?

I'm trying to do a voice quality test (pesq), but I don't understand how to start. I trying to compile a public source code (http://www.itu.int/itu-t/recommendations/index.aspx?ser=P (p.862)) but can't start a test. Maybe anyone work with this?
You will need a C compiler (The ITU PESQ reference implementation is actually C, so you don't need a C++ compiler, although both should work just fine)
For instance, on linux, you would enter the source directory and compile with gcc:
$ cd Software/P862_annex_A_2005_CD/source
$ gcc -o PESQ *.c
This will compile the files dsp.c, pesqdsp.c, pesqio.c, pesqmain.c, pesqmod.c into a binary file PESQ which you can then run with ./PESQ:
$ ./PESQ
Perceptual Evaluation of Speech Quality (PESQ)
Reference implementation for ITU-T Recommendations P.862, P.862.1 and P.862.2.
Version 2.0 October 2005.
<snip long unenlightening IP notice>
Usage:
PESQ HELP Displays this text
PESQ [options] ref deg
Run model on reference ref and degraded deg
Options: +8000 +16000 +swap +wb
Sample rate - No default. Must select either +8000 or +16000.
Swap byte order - machine native format by default. Select +swap for byteswap.
Default mode of operation is P.862 (narrowband handset listening). Select +wb
to use P.862.2 wideband extension (headphone listening).
File names may not begin with a + character.
Files with names ending .wav or .WAV are assumed to have a 44-byte header, which is automatically skipped. All other file types are assumed to have no header.
To run this binary and test your algorithm, you need the "reference" .wav file (This is the clean, original speech) and the "degraded" .wav file (This is the output of your algorithm). Simply pass both into PESQ, and it will give you the output of the test. An example run on two .wav files included in the source distribution from the ITU:
$ cd Software/P862_annex_A_2005_CD/conform
$ ../source/PESQ +8000 or105.wav dg105.wav
Perceptual Evaluation of Speech Quality (PESQ)
Reference implementation for ITU-T Recommendations P.862, P.862.1 and P.862.2.
Version 2.0 October 2005.
<snip IP notice>
Reading reference file or105.wav...done.
Reading degraded file dg105.wav...done.
Level normalization...
IRS filtering...
Variable delay compensation...
Acoustic model processing...
P.862 Prediction (Raw MOS, MOS-LQO): = 2.237 1.844
Where the +8000 parameter denotes that the wav files are sampled at 8000Hz.
In last versions of GCC, you may have to use this comamnd to compile:
gcc -o PESQ *.c -lm
BR
In addition to the answer from staticfloat, and building on the answer from AntoineF, some gcc version might throw the following warnings:
pesqmain.c: In function 'main':
pesqmain.c:322:17: warning: format '%d' expects argument of type 'int', but argument 2 has type 'long int' [-Wformat=]
printf ("An error of type %d ", Error_Flag);
^
pesqmain.c: In function 'pesq_measure':
pesqmain.c:629:35: warning: format '%d' expects argument of type 'int', but argument 3 has type 'long int' [-Wformat=]
fprintf (resultsFile, "%d\t", Fs);
^
pesqmain.c:636:34: warning: too many arguments for format [-Wformat-extra-args]
fprintf (resultsFile, "\n", Fs);
To solve the issue, you can ignore these warnings explicitly by running:
gcc -Wno-format -Wno-format-extra-args -o pesq *.c -lm # works on Ubuntu 16.04, gcc 5.4.0
Hope that can help some people not familiar with compiling C code like me!
Try AQuA software, it's not an ITU-T standard, but solves VoIP speech quality testing very well:
http://www.sevana.fi/voice_quality_testing_measurement_analysis.php
Please, don't use PESQ / ITU-T P.862 anymore. It's superseded by P.863 (aka POLQA) for many good reasons.
For decades, people were using PESQ for applications it was not developed for (e.g., noise reduction, acoustic paths, etc.) - just because it was "available". For PESQ-WB, no one noticed for ~12 years that there was a bug in the implementation (wrong filter coefficients for input bandpass).
Note that even though the source code is available on ITU-T website for download, you need a commercial license to use it! The reference code at ITU-T is only there to re-generate reference results on your specific platform.
Finally: do not rely only on one single MOS metric for voice quality testing. Professionals should use a measurement system like the already mentioned ACQUA software or similar.
Unrar the setup file
Drop both(original and deformed file) file in the conform folder and
execute the file
you will get the results in a notepad