On Wed, 24 Oct 2012, Derek Gaston wrote:
We would like this capability as well.
Right now, what we do is just solve both physics over _all_ of the
processors (one after another)... which isn't always ideal. It
would be great to have more flexibility here - even if it comes at
the cost of a bit more work anywhere that we are doing actual
parallel calls...
The big question I have is about those parallel calls (and parallel
NumericVector initializations, etc):
Although in the short run we'll certainly want their libMesh context
(or Communicator) argument to default to the global LibMeshInit*
target or its Communicator_World, what do we want to do in the long
run?
If we leave that default argument in place, we'll be encouraging
people to write difficult-to-extend code which breaks at runtime in
confusing ways when you try to extend it. We once changed all the
example assembly code from "works with the mesh that example hands it"
to "works with whatever parallel AMR a user might throw at it" simply
because having to help users extend code in such a way is horribly
un-fun.
If we take that default argument away, every single Parallel call in
app code will have to be changed from something like
"Parallel::max(a)" into something like "Parallel::max(a,
mesh.get_libmesh().Communicator_World())", and that's a huge backwards
compatibility breakage to hit users with.
Maybe we could play some tricks with the global LibMeshInit* target to
make extensions easier to debug? E.g. the first LibMeshInit object to
be constructed sets that target from NULL to "this", but then any
subsequent LibMeshInit objects set it back to NULL, so that if it ever
mistakenly gets used in a multi-LibMeshInit application the result is
an immediate and easily-diagnosed segfault rather than a subtle MPI
error/deadlock.
---
Roy
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
_______________________________________________
Libmesh-devel mailing list
Libmesh-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
