Closed gnikit closed 2 years ago
@angus-g : any comments? Looks good to me, but you're probably more qualified as you've dealt with the vagueries of gmsh in fluidity most recently.
On fldecomp: just as a general note fldecomp has been on the "deprecated/to be dropped if it gets too much hassle to maintain" list for a long time but I can see its appeal being fast, simple and serial (which is probably why we never went through with removing it) - flredecomp is meant to be the recommended way to decompose now. Of course we are open to PRs to fix issues with it as long as someone steps up with maintenance (linking to newer versions of vtk has been an issue in the past as well).
Thanks guys!
As for the fldecomp
, it actually has one more feature that flredecomp
does not; compatibility with other AMCG software. FETCH and IC-FERST have different schemas and hence flredecomp
cannot work "out of the box". An edited copy of the source files needs to be held in the corresponding repos, which is just asking for trouble (IMO).
So my idea to not have to not have to worry about fldecomp
maintenance was to simply call the GMSH routines and METIS in Fortran. Reading the mesh and decomposing it with METIS is actually trivial. The main problem that I have had is writing out the decomposed mesh and its halos, using existing Fluidity routines, without making use of MPI.
We can always link back to the existing C++ code to call write_partitions_gmsh
but I thought it might be cleaner if all the mesh decomposing is done in Fortran.
Any thoughts/ ideas on how to generate and output the partitioned meshes and their halos without replicating the code in fldgmsh.cpp
?
A "working" example is given below, with a .geo file and an edited fldecomp/Makefile.in
new_fldecomp.tar.gz
With regards to this I have managed to write a fldecomp
in Fortran that calls our GMSH routines however I have not been able to generate the .halo
s since that requires the use of MPI. Any thoughts on that?
if everyone is okay with this, I think I will merge it once the CI has completed and address fldecomp
in another PR
Sounds good. Yeah, might be tricky to separate the halo writing routines from its mpi dependency. I wouldn't object to a bit of duplication tbh if it's easier (which is the case also in current fldecomp). Main maintenance issue whether this is done in c or fortran is the dependency on metis (rather than parmetis which is what we use in fluidity/flredecomp), but I think we can live with that.
Allows us to read meshes that have $PhysicalNames without aborting. The names are not actually used for anything and are simply ignored.
Probably not the most elegant solution but it did the trick for me. In the future, if we ever decide to use the $PhysicalNames for something a separate routine, similar to the one for $Entities, might be needed.
On a separate note, I noticed that
fldecomp
does not currently work with GMSH 4, which is slightly problematic. Not sure if that should be addressed in this PR.@angus-g Would you mind casting a reviewer's eye?