Fluidity doesn't currently support parmetis 4.0, which is the default for PETSC_3.3

[Rhodri Davies]

The interface for various calls has changed in METIS 5.0 (and above). Examples include METIS_PartGraphKway and METIS_PartGraphRecursive. PETSC 3.3 currently requires parmetis 4.0. Since we are currently trying to move towards supporting PETSC 3.3, and since it's probably sensible to use the same parmetis library within Fluidity, I think the sensible thing would be to modify the Fluidity code path to support parmetis 4.0. Would somebody that understands this code fancy the challenge?! OH GO ON!!! ;-)

[Stephan Kramer (s-kramer)]

So I think there's two issues here: we use metis directly in fldecomp (which we're planning to drop, but this probably need fixing on a shorter timescale) and parmetis via zoltan (https://bugs.launchpad.net/fluidity/+bug/1006863). Afaics there's two ways about to go about this:

1) somehow force the use the older parmetis/metis in the places we use it. Don't really know how to do that
2) upgrade the call (with some #ifdef METIS_VERSION crap) in fldecomp and for parmetis/zoltan we probably need to rebuild zoltan with the newer version of parmetis if we're going to push our own petsc 3.3 package

[Tim Greaves (tim-greaves)]

There's also the issue that (I think!) the plan was to drop ParMETIS requirements entirely to move to Scotch on the basis that the ParMETIS licensing is restrictive for our commercial partners. I believe Gerard was looking into this but have no idea if any progress was made.

[Jon Hill (jon-hill)]

Yes, we should be dropping parMETIS as it's licence is not compatible with LGPL (if you do commercial work, you have to contact the author and pay him some cash).

How is parMETIS used in petsc? Can we compile petsc without it?

[Stephan Kramer (s-kramer)]

Ah, I forgot ParMETIS is non-free and that it's not really required for PETSc (it's also not used in the Debian/Ubuntu PETSc package). So the solution in the short-term is to tell people to simply always build PETSc without parmetis and metis, so we don't get any conflicts.

[James Robert Percival (j-percival)]

If you want to see a rough version of what the code changes are like, see the linked branch. this is taken from the work I did on a mac build, and seems to pass tests there, but I can't guarantee anything. There are issues with implementing a robust version of Stephan's ifdef METIS_VERSION preprocessor code, since one of the changes between v. 4 and v.5 is a complete rewrite of how the header files are arranged so that it's not very easy to pick up version information directly. I think the best way of doing this would be to write an autoconf macro to identify the existence of the relevant functions directly. This is beyond me however, and if we're dropping the package anyway ...

[Jon Hill (jon-hill)]

Assigning to Gerard for now with the long term aim of simply removing parmetis. For now, it seems we have a workaround for everything, yes?

[Adam Candy (asc)]

The OSX build James and I have worked on uses Parmetis 4.0 and Metis 5.0 - as James has discussed above. See also lp:~asc/fluidity/fluidity-darwin-port-minimal. What hasn't been resolved is detecting the version in a nice way - it's currently achieved by a 'DARWIN' flag (which is one of several reasons it hasn't made its way into the trunk yet!)

[Gerard (g-gorman)]

Looking at METIS revision logs we see:

Ver: 5.0.3, March 11th, 2013
  Fixed a bug that was introduced in 5.x for creating nodal graphs from meshes.
  Changed the license to Apache Version 2

fldecomp only uses metis so going forward there is no license issues with fldecomp/METIS.

That said - the interface needs updating.