search

FluidityProject / fluidity

Fluidity
http://fluidity-project.org
Other
365 stars 115 forks source link

$PhysicalNames in GMSH files #330

Closed gnikit closed 2 years ago

gnikit commented 3 years ago

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?

stephankramer commented 3 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).

gnikit commented 3 years ago

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?

MWE

A "working" example is given below, with a .geo file and an edited fldecomp/Makefile.in new_fldecomp.tar.gz

gnikit commented 2 years ago

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 .halos since that requires the use of MPI. Any thoughts on that?

gnikit commented 2 years ago

if everyone is okay with this, I think I will merge it once the CI has completed and address fldecomp in another PR

stephankramer commented 2 years ago

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.