On Tue, 26 Aug 2014, Miguel Angel Salazar de Troya wrote: > I'm trying to call the function DofMap::dof_indices on an element that is > not in my processor and I get a exception thrown when it tries to call > RemoteElem::n_nodes
Yup. If you want information more than one row of cells out, then you'll need to handle the communication at the app level. > My question is more about the details we need to take into account when > trying to implement a function that can be run in distributed processors. > For example, this function is going to check the neighbors for each > element, and it will call the neighbors of the neighbors until a certain > criteria is met. How would we implement this in parallel? Just calling the > local iterators> > > MeshBase::const_element_iterator el = this >> get_mesh().active_local_elements_begin(); > const MeshBase::const_element_iterator end_el = > this->get_mesh().active_local_elements_end(); > > Calling the neighbors of the neighbors could be a problem because they are > too far from the processors border? Exactly. To parallelize a problem like this you basically need an outer while loop with a communication step and element for loops nested inside. I think the best examples in the library are in the mesh refinement smoothing code? > Another question related with the parallelism in libmesh. If within a > libmesh program, I call an external library, will I be calling it once per > processor? Once per MPI rank if you're calling outside of a threaded loop, once per thread if inside. > For example, say that I have an optimization routine that I want > to run it in only one processor, while I want the analysis in libmesh in > parallel. How could I set this up? The naive way is just to test "if (foo->processor_id() == 0)" for some convenient ParallelObject subclass or Communicator foo. This isn't always bad; it's what we do for writing most output to the screen, for instance. This means that your serial optimization routine effectively becomes *n_mpi_ranks* times more expensive, though, as the other processors twiddle their fingers while waiting for the first to be ready to join them. At that point you might as well just run the routine on every processor! To load-balance better, you can set up a dedicated MPI rank for running non-libMesh things: split off an MPI subcommunicator that contains all other ranks, then pass that to LibMeshInit and do your serial calculations on the rank that was left out. --- Roy ------------------------------------------------------------------------------ Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
