This is simple fortran90 program testing MPI.
I would like to compile it on MS Windows platform using MinGW64 Fortran and the known MS-MPI package.
However, it's not working due to missing "mpi.mod". When I replace the use mpi with include 'mpif.h', it's giving other errors (below).
Any help, please ? Does the MS-MPI suite cooperate with the MinGW gfortran ?
PS1:
Working with MS-MPI and MinGW gfortran is not an easy task, https://social.microsoft.com/Forums/en-US/245dcda4-7699-494f-bbe1-b76eb19e53da/linking-msmpi-with-mingw-gfortran?forum=windowshpcmpi
C:\Users\milias\Documents\Dirac\software\autocmake-devel\ms-mpi>gfortran -fno- range-check -c example.f90
mpif.h:344.38:
Included at example.f90:4:
PARAMETER (MPI_AINT=z'4c00043b')
1
Error: PARAMETER attribute of 'mpi_aint' conflicts with PARAMETER attribute at (1)
mpif.h:359.35:
Included at example.f90:4:
PARAMETER (MPI_ADDRESS_KIND=INT_PTR_KIND())
1
Error: Function 'int_ptr_kind' in initialization expression at (1) must be an intrinsic function
solved here, I apologize for the duplicate.
https://github.com/scisoft/autocmake/issues/85#issue-102874399
Related
I am trying to compile a simple program, example.f90
program example
use dsyevd
implicit none
end program example
I am compiling using the command
gfortran -llapack example.f90
However this compilation returns the message
Fatal Error: Cannot open module file 'dsyevd.mod' for reading at (1): No such file or directory
dsyevd is a function in lapack. I have installed intel-mkl onto my computer which contains lapack95. Any advice on how to link my compile to these libraries would be hugely appreciated.
Thank you!
Lapack does not contain any module called dsyevd, so you cannot use it. It is a subroutine so it should be called.
Using -llapack is OK for the default Lapack pre-installed in your Linux distribution. For MKL you must use the appropriate options from the Link Advisor.
Trying to make work MKL_Pardiso on MacOS. I installed Intell Parallel Studio and compile program with fort.
include 'mkl.fi'
INCLUDE 'mkl_pardiso.f90'
program temp
use mkl_pardiso
end program temp
Here is my code to compilier
ifort -mkl temp.f90
The output is
/opt/intel/compilers_and_libraries_2020.1.216/mac/mkl/include/mkl_pardiso.f90(26): error #6218: This statement is positioned incorrectly and/or has syntax errors.
MODULE MKL_PARDISO_PRIVATE
Why does this happen? should I use another flags?
please try build as follows: ifort -mkl mkl_pardiso.f90 temp.f90
Sort briefing what I am trying to do:
I want to use vnode-lp on my windows PC. I’ve installed MinGW. I’ve installed the necessary dependencies like LAPACK & BLAS libraries as well as Profil/BIAS. The installation of all libraries passed the make and make install process without errors. I hope (!) I’ve managed to install it correctly.
Now the Problem:
Now I’ve tried to get a simple program compiled with basically northing in it just an #include “vnode.h”. First I tried it with Microsoft Visual Studio. Since this gave me several errors I tried to compile it with g++ using MinGW. This gives me the same errors. It starts with
./matrix.w:90:17: error: ‘v_bias’ is not a namespace-name
The Question:
How to include vnodelp into an c++ program and compile it without errors under windows, am I missing something?
Off-topic:
I am trying to get this running for over a week now and don’t know what to do anymore.
C++ is most definitely not C, and packages designed for C++ will never compile and run as C code. So, what you're trying to do really can't be done unless you do some fancy stuff by creating a .dll or something like that, and even then I think you wouldn't get the functionality you want. Why not write your code in C++ and compile with g++ or a similar compiler?
I have managed to finally solve this issue. In case someone has the same problem here is the solution.
I have missed something in the call. Here is the full call that has worked for me:
g++ -o2 –Wall –Wno-deprecated –DNDEBUG – DPROFIL_VNODE – DMAXORDER=50 –I(path to profil bias)/include –I(path to profil bias)/include/BIAS –I(path to profil bias)/src/Base –I(path to vnodelp)/FADBAD++ -I../include –DNDEBUG –c –o (filename).o (filename).cc
g++ -L(path to profil bias)/lib –L(path to lapack)/lib –L../lib –o (filename) (filename).o –lvnode –lProfil –lBias –llr (path to lapack)/lib/liblapack.lib (path to lapack)/lib/libblas.lib –lstd++
funfact:
This also complies with gcc instead of g++
I try to compile the fortran program which my advisor gave me.
It doesn't want to compile when I'm doing this with gfortran 4.7.2 on Mac OS X 10.8.4 and with gfortran 4.8.1 on Arch Linux x64.
I've built the minimal working example which replays the error. Unfortunately, it's quite big anyway, so I've put it on the github: https://github.com/kabanovdmitry/vode-test
I can compile this code under Ubuntu 12.04 with gfortran 4.6.3.
I've checked press releases for GCC 4.7 and found nothing that could give me a clue.
Could you please shed some light why gfortran doesn't want to compile this code?
Sorry, initially forgot to put the errors here:
main.f90:8.75:
call vode(istate, lambda_fcn, dummy_jac, lambda, x_tmp, x_end, tol, pm)
1
Error: There is no specific subroutine for the generic 'vode' at (1)
make: *** [all] Error 1
Your problem is covered by my answer and its comments in the question referenced by george. The type, kind and rank of arguments match exactly. To add something new, I suggest you to try to call the specific procedure directly. The type checker will then complaint for bad actual arguments and you will see more details.
In your case
generic2.f90:81.24:
call d_vode(istate, lambda_fcn, dummy_jac, lambda, x_tmp, x_end, tol, pm)
1
Error: Interface mismatch in dummy procedure 'f' at (1): Shape mismatch in dimension 1 of argument 'y'
Which is rather self-explaining. You dummy procedures are not compatible with your interfaces. You are mixing assumed-size and constant-size and explicit size arrays. You must follow the interface exactly.
I was wondering if someone could help me with this.
I've retrieved the source code for the gnuplot-iostream interface from http://www.stahlke.org/dan/gnuplot-iostream/. However, when I attempt to compile the code using the command:
]$ cmake .; make
I get the following compiler error
/.../gnuplot-iostream.h: In constructor ‘Gnuplot::Gnuplot(const std::string&)’:
/.../gnuplot-iostream.h:427: error: ‘never_close_handle’ is not a member of ‘boost::iostreams’
I'm using Scientific Linux 6.2 (kernal 2.6.32-220.23.1.el6.x86_64), g++ 4.4.6, and have boost libraries installed (/usr/include/boost/iostreams/ exists).
Any assistance would be very much appreciated.
D
enum file_descriptor_flags was added in boost::iostreams only in 1.44.0.
enum file_descriptor_flags
{
never_close_handle = 0,
close_handle = 3
};
So, the solution is simply update the boost library (thanks ForEveR).
If however, like me, you do not have the access to update the libraries on your system you should note that I was able to force compilation and obtain basic functionality by simply replacing the two occurrences of boost::iostreams::never_close_handle in the gnuplot-iostream.h file with 0.