need help calling C from Fortran

[Brian_Murphy]

I am trying to use a numerical library called UMFPACK.  20 years ago it was all fortran, but today it's in C.  The attached fortran file is a supplied sample Main program to demonstrate calling umfpack from a fortran program.  The attached C file contains C wrapper routines being called from fortran.  When I build it, I get unresolved externals for all the C routines being called from fortran.

I looked at the Intel sample project called "Fortran-Calls-C", but the Microsoft C compiler wouldn't let me put  extern "C" into umfpack's c file.  Maybe that's a good thing, because I really don't want to be editing their C files because there is a large number of them.

How do I get this to work?

[mecej4]

In that case, Pardiso should work fine. Please try it.

[Brian_Murphy]

I plan to give it a try later today.  I will start by seeing if I can build Pardiso examples in C:\Program Files (x86)\Intel\Composer XE 2013\mkl\examples\solverf\source.  I see there are both f77 and f90 examples.

The gateway to Pardiso documentation seems to be at:

https://software.intel.com/en-us/node/470282#88F30007-9094-42EB-A4B1-8401F0C43ABE

Do you know if the entire collection of Pardiso documentation available as a single pdf?

[mecej4]

There is a PDF version of the MKL manual at https://software.intel.com/en-us/mkl-reference-manual-for-fortran-pdf , which includes a section on Pardiso. There is also the Pardiso-5.0 manual at http://www.pardiso-project.org/manual/manual.pdf, but note that the MKL-Pardiso and the Basel-Lugano versions are slightly different.

[mecej4]

Here is an update on how the _ci_ _zi_ ... mystery that was touched upon in #7.

Suitesparse and Umfpack use preprocessor definitions to build different versions of object files from a single source file. The makefiles that come with Suitesparse take care of building these multiple object file versions. However, if a different build system is used other than Make, problems arise, as we have seen.

For a different solution based on Cmake and scripts, see https://github.com/jlblancoc/suitesparse-metis-for-windows .

As an exercise, I built Suitesparse on Linux using make CC=icc FC=ifort CXX=icc LD=icc, and the whole build/verify process seemed to complete normally. Calling the library from Fortran was done using the wrapper files provided (such as umf4_f77wrapper.c).

Some distributions of Linux provide Umfpack in a Linux package.

[Brian_Murphy]

I want to do all my development work with Visual Studio.  I've got VS 2012 installed on my host Win7 system.  Plus I've got VS 2010 installed in a Win7 virtual machine because the 2012 version has weird problems debugging.

Next up is trying Pardiso as a replacement for umfpack.  But first I have to take care of a few other things before I can get back on this. 

I successfully downloaded the pdf manual for mkl.  3000+ pages!  Thanks for the link to it.

[Brian_Murphy]

On my Win7 computer, I have successfully built and run the pardiso_sym_f90.f90 example as a console application.  It will run either in a command prompt window, or in the visual studio 2012 debugger.  Everything works fine except for the following error message during the build process.

Error    1     general error c101008d: Failed to write the updated manifest to the resource of file "C:\Users\Brian\Documents\Visual Studio 2012\Projects\Pardiso example\Pardiso example\Debug\Pardiso example.exe". The operation failed.    mt.exe

I tried a 32 bit Release version, and it also runs fine, and generates the same build error.  I then tried x64 in Debug and Release.  Those run fine and do not generate any build errors.

I'm using pretty much all the defaults of Visual Studio 2012.  The compile and link command line strings for Release32 are as follows:

/nologo /O2 /module:"Release\\" /object:"Release\\" /Fd"Release\vc110.pdb" /libs:static /threads /Qmkl:sequential /c

/OUT:"Release\Pardiso example.exe" /INCREMENTAL:NO /NOLOGO /MANIFEST /MANIFESTFILE:"C:\Users\Brian\Documents\Visual Studio 2012\Projects\Pardiso example\Pardiso example\Release\Pardiso example.exe.intermediate.manifest" /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /SUBSYSTEM:CONSOLE /IMPLIB:"C:\Users\Brian\Documents\Visual Studio 2012\Projects\Pardiso example\Pardiso example\Release\Pardiso example.lib"

The EXE files for this tiny example program are huge!  Debug32 is 11 mb, Release32 is 10 mb, Debug64 is 24 mb, Release64 is 23 mb.

Switching from Fortran>Libraries>Runtime Library>Multithreaded to Multithreaded DLL made Release32 only 22k, but for deployment purposes I don't want to use DLL for the builds.  Are there any other ways to reduce the EXE size?  The only thing I'm using from MKL is LU factoring and solving?

[mecej4]

As to the manifest files: they are a nuisance when a small program is being built and run several time for debugging purposes. They may also run into problems with (i) write permissions in the directory where they are created, and (ii) non-peaceful coexistence with virus checkers. You can turn off manifest generation and embedding by setting the property Project-Linker-Manifest File-Generate Manifest to "No". You can tell your AV software to exclude the build directory from its snooping.

Even small programs with less than 200 lines of Fortran code can produce huge EXE files when they call Paradiso/DSS in MKL. Here is an example, compiled against DLL libraries.

09/01/2015  03:51 PM             6,522 sym.f
09/01/2015  03:52 PM             6,683 sym.obj
09/01/2015  03:52 PM            28,672 sym.exe

The same program, built with static libraries:

09/02/2015  09:01 PM             6,642 sym.obj
09/02/2015  09:01 PM        23,238,656 sym.exe

My suggestion is that you use DLL libraries during development and shift to static libraries when you release the software to users. Are you aware that Intel provides redistributables packages that users can obtain and use without charge?

[Brian_Murphy]

This Manifest business is new to me.  I turned it OFF and rebuilt the sample EXE program, and the error went away. 

My final build target is a DLL.  So the help file makes it sound like I can turn manifest OFF and won't really matter.

About the huge files.  I recall seeing somewhere the use of an ONLY keyword when using code from other sources.  Can I do something like that to make my own statically built DLL smaller?

Today I will be working on implementing Pardiso in my application.  My code uses what is basically Coordinate storage for the sparse matrix.  So I think I need to change it to CSR in order to use Pardiso.  The Pardiso pdf file contains the following:

mkl_sparse_convert_csr
Converts internal matrix representation to CSR
format.

Does the MKL have routines to make a CSR matrix from a Coordinate storage format matrix?  I suppose I would first have to convert Coordinate to "internal", and then from "internal" to CSR, but it's not clear if that can be done.

[mecej4]

See https://software.intel.com/en-us/node/468628 for MKL routines dcsrcoo and zcsrcoo.

[Brian_Murphy]

"Ahhh, I see!" said the blind man.

I'm working on it now :)

[Brian_Murphy]

I have the compile option set in Fortran>Libraries>Use Intel Math Kernel Library> /Qmkl:sequential, but I'm getting an unresolved external for dcsrcoo. 

What am I missing?

I tried adding INCLUDE 'mkl.fi' but that generates loads of compile errors.  I think because mkl.fi, and other files included by it, are not compatible with fixed format source files and the 132 column option.

Right now I'm modifying my source file so it doesn't need the 132 column option.  Hopefully then mkl.fi can be included, and the unresolved external will be cured.

[Brian_Murphy]

That didn't work.  Now I can't include 'mkl_pardiso.f90' because it needs 132 columns.

This seems to be forcing me to free format.  The ARPACK code I'm using requires fixed format.  It looks like I've got work to do breaking things apart so they will compile.  I don't see any other way.

[Brian_Murphy]

I think I will try switching to INCLUDE 'mkl_pardiso.f77' and keep my file fixed format and 72 columns.

[mecej4]

The interfaces are helpful to check if your calls have correct argument types, but they are not necessary for the routines in question.

Did you use the proper name for the routine, which is "mkl_dcsrcoo" ?

[Brian_Murphy]

Darn.  I left out the mkl_.  I have to leave it for now, but I'll be back on it this later this evening or tomorrow.

[Brian_Murphy]

I'm back on it, and pardiso is crashing on me at the factoring phase.  Should I ask for help here, or in the mkl forum?