>     Ideally, both systems should be parallelized such that of a
>     total of N processors, the first system is parallelized to (and solved
>     on) M processors, while the other N-M processors are handling the other
>     system. What is the intended way (if any) to do this? Initialize libmesh
>     twice, with different MPI communicators?
>
>
> There probably isn't a reason to do this.  Are you literally going to
> call "solve()" simultaneously on both systems?  Most likely you will
> solve one then the other right?  If that's the case just let them use
> the same processors.


Well, I'm using my own custom Systems, which have their own solve(), but 
in principle: yes. They will probably end up having to communicate in 
between single substeps of their solve(), but communication will always 
happen after full mesh sweeps, so that shouldn't be a problem.

The reason why letting them use the same procs is likely not going to 
work so well in my case is that one of the two systems is not going to 
scale, or even worse, it will have a speedup of less than one. So I 
expect M=1, i.e., only one of the two systems can be reasonably 
parallelized.

So, I see two possibilities here:
1) Actually letting them use the same procs. Problem: How to disable 
parallelism for the first system in order to avoid a speedup of less 
than one, while still having the second system run in parallel.
2) Letting one processor solve the first system and the other N-1 the 
second. Likely, with N=4 or so, the load would be well balanced. But 
that essentially coincides with my original intention.


Roman

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Libmesh-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libmesh-users

Reply via email to