Thanks for your response. I'll take a look at the mesh smoothers to see if I can apply something similar. One question related to parallelism. I see that most of the assembly routines are implemented using TBB. I configured my libmesh with this library. Now, does this mean I'm using it when I run my program? Is there a special way to compile/run the program in order to take advantage of the TBB perks?
Miguel On Tue, Aug 26, 2014 at 3:46 PM, Roy Stogner <[email protected]> wrote: > > 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 > -- *Miguel Angel Salazar de Troya* Graduate Research Assistant Department of Mechanical Science and Engineering University of Illinois at Urbana-Champaign (217) 550-2360 [email protected] ------------------------------------------------------------------------------ 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
