<br clear="all"><br><br><div class="gmail_quote">On Wed, Jul 11, 2012 at 7:05 PM, Berk Hess <span dir="ltr">&lt;<a href="mailto:hess@kth.se" target="_blank">hess@kth.se</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">On 07/11/2012 06:51 PM, Christoph Junghans wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2012/7/11 Roland Schulz &lt;<a href="mailto:roland@utk.edu" target="_blank">roland@utk.edu</a>&gt;:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Wed, Jul 11, 2012 at 7:19 AM, Alexey Shvetsov<br>
&lt;<a href="mailto:alexxy@omrb.pnpi.spb.ru" target="_blank">alexxy@omrb.pnpi.spb.ru</a>&gt; wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Roland Schulz писал 2012-07-11 10:47:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Wed, Jul 11, 2012 at 2:33 AM, Alexey Shvetsov<br>
&lt;<a href="mailto:alexxy@omrb.pnpi.spb.ru" target="_blank">alexxy@omrb.pnpi.spb.ru</a>&gt; wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi!<br>
<br>
mvpich2/mvapich (as well as its derviations like platform<br>
mpi,pc-mpi,intel-mpi) also will behave differently. So user can get<br>
cryptic message about launching mpd, in case of launching mdrun -np<br>
directly<br>
</blockquote>
Not quite. mpich2 requires for MPI_Comm_spawn to work that the<br>
application is run with mpirun/mpiexec. See<br>
<br>
<a href="http://lists.mcs.anl.gov/pipermail/mpich-discuss/2012-June/012638.html" target="_blank">http://lists.mcs.anl.gov/<u></u>pipermail/mpich-discuss/2012-<u></u>June/012638.html</a><br>
for the details. We would need to detect that and don&#39;t try to spawn<br>
in that case (and run in serial with a warning).<br>
Thus mpich2 would require: mpirun mdrun -np x. Of course that isn&#39;t<br>
more convenient than mpirun -np x mdrun. The only advantage would be<br>
that as with tmpi &quot;mpirun mdrun&quot; would automatically use as many<br>
cores<br>
as are available and are useful for the system, whereas without spawn<br>
the user needs to decides the number of cores and we can&#39;t have any<br>
automatic mechanism helping the user.<br>
<br>
Roland<br>
</blockquote>
Ok. But how this will work with batch systems that automaticaly send<br>
number of processes to mpiexec, effective launch command will be<br>
<br>
$ mpiexec mdrun_mpi $mdrunargs<br>
</blockquote>
The idea was to only do any spawn if mdrun_mpi is started in serial<br>
(mpiexec -n 1). It was only meant to make mdrun_mpi behave the same as<br>
tmpi mdrun for a single node. On clusters with batch system nothing<br>
would have changed over the current situation.<br>
</blockquote>
1.) I agree with Roland that keeping the -nt option would be<br>
misleading, even if -nt gets a new meaning - &quot;number of tasks&quot;, where<br>
tasks can be threads or mpi tasks.<br>
Also from my experience, half of the users are not aware of the -nt<br>
option either, they just start mdrun without any special setting,<br>
which means &quot;guess&quot; and we should keep that.<br>
So making -nt obsolete is not bad, I think.<br>
</blockquote></div></div>
In my last mail the proposition was to only use -nt for the total number of threads<br>
and not with MPI. I think this is useful, since the user usually would want to limit<br>
the total number of threads (or cores used) and would not know what to choose<br>
for -ntmpi and -ntomp.<div class="im"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
2.) One class of system that has not been discussed yet, are the one<br>
with different number of OMP threads per node (like the Intel MIC),<br>
that should also be possible by explicitly defining OMP_NUM_THREADS on<br>
each node.<br>
</blockquote></div>
How doesn MIC have different numbers of threads per node?</blockquote><div><br></div><div>It acts as an individual compute node with its own OS (and network?). I&#39;ve no idea how is one supposed to be using it with MPI+OpenMP, but I assume one wouldn&#39;t just slap 512 OpenMP threads on the card as that won&#39;t be fast.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
3.) With all these thread options and combination, we will need<br>
something like g_tune_mdrun, which I guess could be an extension of<br>
g_tune_pme.<br>
</blockquote></div>
Except for the scaling limit, there is usually once best choice.<br>
But for running close to the scaling limit a g_tune_mdrun could indeed help.<br>
<br>
Cheers,<br>
<br>
Berk<div class="HOEnZb"><div class="h5"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Christoph<br>
<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Roland<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Roland Schulz писал 2012-07-11 05:09:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Tue, Jul 10, 2012 at 8:09 PM, Szilárd Páll<br>
&lt;<a href="mailto:szilard.pall@cbr.su.se" target="_blank">szilard.pall@cbr.su.se</a>&gt; wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Tue, Jul 10, 2012 at 11:15 PM, Berk Hess &lt;<a href="mailto:hess@kth.se" target="_blank">hess@kth.se</a>&gt; wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<br>
We are working on the final part of the 4.6 release, which is<br>
making the MPI<br>
and OpenMP thread setup automated, fully checked and user<br>
friendly.<br>
We have to decide on the naming of the options.<br>
Roland has an implementation of mpi spawn ready. This would allow<br>
to do<br>
mdrun -np #processes instead of using mpirun (at least with<br>
openmpi).<br>
</blockquote>
Would this feature add anything but the convenience of being able<br>
to<br>
run without mpirun on a single node? Without MPI spawning working<br>
reliably in most cases (or with the ability to detect with a high<br>
certainty when it does not), enabling an -np mdrun option would<br>
just<br>
lead to confusion when mdrun exits with cryptic MPI error due to<br>
not<br>
being able to spawn.<br>
</blockquote>
The idea was to make mdrun behave the same whether it is compiled<br>
with<br>
real MPI or tMPI. Thus also only support a single node. But MPICH<br>
is<br>
behaving quite stupid and they also don&#39;t seem to care. And only<br>
supporting it for OpenMPI is probably also more confusing then<br>
helpful<br>
(then tmpi+OpenMPI would behave the same but MPICH/MVAPICH would<br>
behave different). So you are probably right that it is better to<br>
not<br>
add spawn at all.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Therefore, I&#39;d be OK with a new *hidden* -np option that only<br>
works<br>
in<br>
single-node case, but not with a non-hidden one advertised in the<br>
documentation/wiki.<br>
</blockquote>
As a hidden option it would only help for testing. But I don&#39;t<br>
think<br>
it is worth adding it for just that.<br>
<br>
Roland<br>
</blockquote>
--<br>
Best Regards,<br>
Alexey &#39;Alexxy&#39; Shvetsov<br>
Petersburg Nuclear Physics Institute, NRC Kurchatov Institute,<br>
Gatchina, Russia<br>
Department of Molecular and Radiation Biophysics<br>
Gentoo Team Ru<br>
Gentoo Linux Dev<br>
mailto:<a href="mailto:alexxyum@gmail.com" target="_blank">alexxyum@gmail.com</a><br>
mailto:<a href="mailto:alexxy@gentoo.org" target="_blank">alexxy@gentoo.org</a><br>
mailto:<a href="mailto:alexxy@omrb.pnpi.spb.ru" target="_blank">alexxy@omrb.pnpi.spb.ru</a><br>
--<br>
gmx-developers mailing list<br>
<a href="mailto:gmx-developers@gromacs.org" target="_blank">gmx-developers@gromacs.org</a><br>
<a href="http://lists.gromacs.org/mailman/listinfo/gmx-developers" target="_blank">http://lists.gromacs.org/<u></u>mailman/listinfo/gmx-<u></u>developers</a><br>
Please don&#39;t post (un)subscribe requests to the list. Use the<br>
www interface or send it to <a href="mailto:gmx-developers-request@gromacs.org" target="_blank">gmx-developers-request@<u></u>gromacs.org</a>.<br>
<br>
<br>
<br>
</blockquote>
<br>
<br>
--<br>
ORNL/UT Center for Molecular Biophysics <a href="http://cmb.ornl.gov" target="_blank">cmb.ornl.gov</a><br>
865-241-1537, ORNL PO BOX 2008 MS6309<br>
</blockquote>
--<br>
Best Regards,<br>
Alexey &#39;Alexxy&#39; Shvetsov<br>
Petersburg Nuclear Physics Institute, NRC Kurchatov Institute,<br>
Gatchina, Russia<br>
Department of Molecular and Radiation Biophysics<br>
Gentoo Team Ru<br>
Gentoo Linux Dev<br>
mailto:<a href="mailto:alexxyum@gmail.com" target="_blank">alexxyum@gmail.com</a><br>
mailto:<a href="mailto:alexxy@gentoo.org" target="_blank">alexxy@gentoo.org</a><br>
mailto:<a href="mailto:alexxy@omrb.pnpi.spb.ru" target="_blank">alexxy@omrb.pnpi.spb.ru</a><br>
--<br>
gmx-developers mailing list<br>
<a href="mailto:gmx-developers@gromacs.org" target="_blank">gmx-developers@gromacs.org</a><br>
<a href="http://lists.gromacs.org/mailman/listinfo/gmx-developers" target="_blank">http://lists.gromacs.org/<u></u>mailman/listinfo/gmx-<u></u>developers</a><br>
Please don&#39;t post (un)subscribe requests to the list. Use the<br>
www interface or send it to <a href="mailto:gmx-developers-request@gromacs.org" target="_blank">gmx-developers-request@<u></u>gromacs.org</a>.<br>
<br>
<br>
<br>
</blockquote>
<br>
<br>
--<br>
ORNL/UT Center for Molecular Biophysics <a href="http://cmb.ornl.gov" target="_blank">cmb.ornl.gov</a><br>
865-241-1537, ORNL PO BOX 2008 MS6309<br>
--<br>
gmx-developers mailing list<br>
<a href="mailto:gmx-developers@gromacs.org" target="_blank">gmx-developers@gromacs.org</a><br>
<a href="http://lists.gromacs.org/mailman/listinfo/gmx-developers" target="_blank">http://lists.gromacs.org/<u></u>mailman/listinfo/gmx-<u></u>developers</a><br>
Please don&#39;t post (un)subscribe requests to the list. Use the<br>
www interface or send it to <a href="mailto:gmx-developers-request@gromacs.org" target="_blank">gmx-developers-request@<u></u>gromacs.org</a>.<br>
</blockquote>
<br>
<br>
</blockquote>
<br>
<br>
-- <br>
gmx-developers mailing list<br>
<a href="mailto:gmx-developers@gromacs.org" target="_blank">gmx-developers@gromacs.org</a><br>
<a href="http://lists.gromacs.org/mailman/listinfo/gmx-developers" target="_blank">http://lists.gromacs.org/<u></u>mailman/listinfo/gmx-<u></u>developers</a><br>
Please don&#39;t post (un)subscribe requests to the list. Use the www interface or send it to <a href="mailto:gmx-developers-request@gromacs.org" target="_blank">gmx-developers-request@<u></u>gromacs.org</a>.<br>
</div></div></blockquote></div><br>