1. SIGMA Avatar SIGMA
  2. Components
  3. MOAB
  4. Issues

Fortran support always required because of LAPACK

Issue #72 resolved
Paul Wilson created an issue

The introduction of a LAPACK dependency means that FORTRAN support is always required. The current CMake build implies that this is only the case for some options (iMesh and FBIGEOM), but this is not actually true. (see #39)

Without Fortran support there is no way to define the MOAB_FC_FUNC macro needed to build Matrix3

Comments (14)

  1. Paul Wilson reporter

    These wrappers are used in three places: * Matrix3 * imoab_protos * MBCN_protos

    The latter two include a work around such that if MOAB_FC_FUNC is not defined it effectively does a no-Op, prehaps since it doesn't matter in a non-FORTRAN case.

    I think since LAPACK is a FORTRAN based library, it is always going to have FORTRAN based name mangling that needs to be decoded, so that all places that LAPACK is used require FORTRAN to be supported to determine the form of the name mangling.

    This is an important new non-optional dependency for MOAB.

  5. Vijay M

    Hmm I think one of our users also had a similar issue with autotools, when they didn't have Fortran compiler installed. I find it weird that they were able to install BLAS without fortran runtime.

    We will also harden this support on CMake side. And will make this a high priority fix too.

  6. Paul Wilson reporter

    I discovered all this by trying to build in Windows, where you can download binary BLAS and LAPACK libraries that may/may not require fortran runtimes... I was trying to do it without MinGW, but I think it will be necessary.

    I can PR the CMake fix for this that will make FORTRAN a strict requirement and therefore more consistent with the autotools build.

  7. Vijay M

    Ah, Windows. Our Kryptonite.

    I can PR the CMake fix for this that will make FORTRAN a strict requirement and therefore more consistent with the autotools build.

    Thanks, this will be much appreciated!

  9. Paul Wilson reporter

    We really want (need?) Windows to work. Some new CMake capability should make this mostly straightforward, but the LAPACK dependency is mildly annoying :).

  10. Paul Wilson reporter

    How would you feel about vendoring clapack into this repo and setting up the build to optionally build/use it if there is no system LAPACK? It would take a little work, but probably doable...

  11. Vijay M

    Hmm we could. It should be easy to add support for the autotools system for this but we currently don't have something like a "superbuild" system for CMake. I definitely do not want to distribute LAPACK with MOAB. If you are thinking about downloading during configuration, I think this will be good.

    On a separate note, we could just distribute the LAPACK/BLAS sources that are only used in MOAB for such cases. However, I found it painful to get the right set of files so that we have a complete symbol list. So dropped this idea.

  12. Paul Wilson reporter

    Agreed that getting the right symbol list is a bit of a nightmare...

    I'll start by getting it to just work with CLAPACK (either in Windows or Linux) and go from there...

  13. Vijay M

    Is this still an issue ? I think enabling Eigen3 should resolve this issue independent of the architecture. The performance from Eigen is quite good for most cases if a full LAPACK build is available.

    But we may have to add code to skip Fortran checks if Eigen is available. Unsure if we have those in place.

  15. Log in to comment
Assignee
Type
bug
Priority
major
Status
resolved
Component
–
Version
5.0.0
Votes
0
Watchers
1