Fortran bindings are built but not installed

[jvo203]

Fortran bindings can be built by issuing cmake -DBUILD_ZFORP=ON .. followed by make. But then issuing sudo make install installs under /usr/local/ the usual zfp C/C++ library only, without the Fortran bindings (Fortran module + libzFORp.so).

[lindstro]

Indeed, this is related to #122 and we'd like to address it for the next release. I'm not sure what directory structure is expected for installed Fortran modules. If you're willing to make a contribution, we'd gladly accept it.

[jvo203]

Further observations: Fortran bindings work fine without sudo make install if one links to the module/library from within the cmake "build" folder. But they work only with gfortran, not ifort.

With gfortran the test program compiles and works:

gzfp:
	gfortran -Ofast -I/home/chris/zfp/build/modules tests/zfp_compress.f90 -o zfp_compress -L/home/chris/zfp/build/lib64 -lzFORp

Intel's ifort does not accept module files compiled with other compilers ( I guess Fortran module files are simply not portable). So one needs to pass a Fortran compiler name/path to zfp, like so:

gmake BUILD_ZFORP=1 FC=ifort

Unfortunately Fortran ZFP bindings fail to compile this way because i) ifort does not recognise gfortran compile flags, ii) zfp.f has a default F77 file extension, ifort fails to compile it, zfp.f should be renamed to zfp.f90 for ifort to swallow it.

So right now in order to use ifort I had to do this:

zfp:
	ifort -Ofast -xHost -mavx -axAVX -qopt-report=2 tests/zforp.f90 tests/zfp_compress.f90 -o zfp_compress -L/home/chris/zfp/build/lib64 -lzfp

Basically rename zfp.f to zforp.f90 (I want to reserve the zfp.f90 name for other purposes, hence the name change too, not just an extension), then compile it explicitly together with the test program and link with the "normal" C libzfp library. It is a bit of a hack but it works.

Regarding the placement of a Fortran module file zforp_module.mod during installation, my best guess would be to put it alongside ZFP C include files in /usr/local/include so that it can be found by default. And put libzFORp.so in say /usr/local/lib64 alongside other ZFP library files. Plus building ZFP with ifort should be fixed too by renaming zfp.f to zfp.f90 (ifort will simply ignore unknown gfortran compilation flags and should proceed with the compilation).

[jvo203]

And one more thing, the current Fortran ZFP module name as it appears in zfp.f seems to be unnecessarily complicated: it ends with "_module". I simplified it to just zFORp, plus changed the "use" statement accordingly in the Fortran bindings test file to just use zFORp, like so:

zfp.f90:

module zFORp
(...)
end module zFORp

[lindstro]

Thanks for your suggestions. I don't know the rationale for the _module suffix or why we're not using an f90 extension. Unfortunately, the original author is no longer with our project.

We'll take a closer look at this over the coming weeks.

[lindstro]

@jvo203 Does the fix on 6389b89 address your concerns? If so, then I'd like to go ahead and close this issue.

[jvo203]

Hi Peter,

Thank you and yes the issue can be closed.

Though by this time I have analysed and re-created ZFP in native FORTRAN as well as Intel SPMD C (ispc)... The native FORTRAN implementation is not general, it is specific to my needs and ties closely with the rest of the FITSWEBQLSE FORTRAN code. The intention is to take a full advantage of CPU L1 cache, operate on 4x4 blocks held in the L1 cache and only decompress on demand small portions of the large widthxheight 2D array (similar to your caching).

And as of last week I switched from Co-Array FORTRAN to Julia. Julia is like FORTRAN on steroids and, compared with Co-Arrays, has better distributed computing (distributed arrays etc.).

Chris

[lindstro]

Sounds interesting. We've been thinking about putting FORTRAN wrappers around our cfp C bindings to zfp's compressed-array classes, but the demand for such a feature has not yet been high enough for this to override other priorities. Some day...