Re: [fem-fenics] MPI parallelisation

[Marco Vassallo]

On Sun, Aug 3, 2014 at 2:47 PM, Eugenio Gianniti <address@hidden> wrote:

I pushed to my repository some changesets that allow for the solution of problems in parallel via the MPI paradigm. Namely:

  * ufl.m and all the import_ufl_*.m are executed only by the main process, since they perform IO;

  * in parallel execution meshes are built from the p-e-t input argument and then distributed among processes;

  * matrices and vectors are assembled locally and then gathered to obtain the global ones on the main process;

  * Mesh.oct now can return as output arguments up to two meshfunctions storing facet or cell markers, since in parallel runs Meshes cannot store that information themselves with the current implementation of the DOLFIN library.

Tomorrow I will provide more details on my blog.

 

Currently when using MPI one must use the meshfunction returned by Mesh.oct in order to provide DirichletBC.oct with the markers identifying subsets of the boundary. There are a couple of points that could be discussed. First of all, as of now DirichletBC.oct accepts as argument also a meshfunction identifying subdomains. I used this approach because I did not find an alternative for the storage of this information: MeshData, the class I mentioned previously, does not help in this task, as far as I understand. Anyway, dolfin::DirichletBC offers a constructor with the same signature as the current DirichletBC.oct, so this is not really weird.

A second aspect is that meshfunction is actually very, very raw. Currently there is no way to display it, no function to build it as users need… Moreover, its name is quite misleading, as dolfin::MeshFunction is a template class, whilst meshfunction wraps dolfin::MeshFunction <std::size_t>. For the first issues I think I can provide easily functionality as importing/exporting a MeshFunction from/to file, a descriptive line to display like in other fem-fenics types, etc. For the latter, I do not know if it could be meaningful to make meshfunction itself a template class or just provide three wrappers for <std::size_t>, <bool> and <double>, which are the most recurring instances in FEniCS documentation. Or even just leave it as it is and say it in the package documentation.

I think that the solution with the meshfunction as a template is better but I don't know how hard it could be to achieve. As we are entering the last week before the "suggested" pencil down deadline ( 11th of August), a good idea could be to give a try to the template solution for the first few days of the next week. If we realize that it is too difficult, we could switch to the solution with the multiple wrappers, which should be quite easy to do as it is similar to many other you have already done.

Marco

 

Eugenio