<br><br><div class="gmail_quote">On Thu, Oct 28, 2010 at 11:30, Satrajit Ghosh <span dir="ltr">&lt;<a href="mailto:satra@mit.edu">satra@mit.edu</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

hi brian,<br><br>thanks for the responses. i&#39;ll touch on a few of them.<br><br>
<div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex"><div>&gt; * optionally offload the dag directly to the underlying scheduler if it has<br>



&gt; dependency support (i.e., SGE, Torque/PBS, LSF)<br>
<br>
</div>While we could support this, I actually think it would be a step<br>
backwards. <br></blockquote></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">... <br></blockquote><div class="im"><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">


All of this means lots and lots of latency for each task in the DAG.<br>
For tasks that have lots of data or lots of Python modules to import,<br>
that will simply kill the parallel speedup you will get (ala Amdahl&#39;s<br>
law).<br></blockquote></div><div><br>here is the scenario where this becomes a useful thing (and hence to optionally have it). let&#39;s say under sge usage you have started 10 clients/ipengines. now at the time of creating the clients one machine with 10 allocations was free and sge routed all the 10 clients to that machine. now this will be the machine that will be used for all ipcluster processing. whereas if the node distribution and ipengine startup were to happen simultaneously at the level of the sge scheduler, processes would get routed to the best available slot at the time of execution. <br>

</div></div></blockquote><div><br></div><div>You should get this for free if our ipcluster script on SGE/etc. can grow/shrink to fit available resources.  Remember, jobs don&#39;t get submitted to engines until their dependencies are met.  It handles new engines coming just fine (still some work to do to handle engines disappearing gracefully). Engines should correspond to actual available resources, and we should probably have an ipcluster script that supports changing resources on a grid, but I&#39;m not so sure about the scheduler itself.</div>

<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote"><div><br>i agree that in several other scenarios, the current mechanism works great. but this is a common scenario that we have run into in a heavily used cluster (limited nodes + lots of users).<br>

 </div><div class="im"><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">

<div>&gt; * something we currently do in nipype is that we provide a configurable<br>
&gt; option to continue processing if a given node fails. we simply remove the<br>
&gt; dependencies of the node from further execution and generate a report at the<br>
&gt; end saying which nodes crashed.<br>
<br>
</div>I guess I don&#39;t see how it was a true dependency then.  Is this like<br>
an optional dependency?  What are the usage cases for this.<br></blockquote></div><div><br>perhaps i misunderstood what happens in the current implementation. if you have a DAG such as (A,B) (B,E) (A,C) (C,D) and let&#39;s say C fails, does the current dag controller continue executing B,E? or does it crash at the first failure. we have the option to go either way in nipype. if something crashes, stop or if something crashes, process all things that are not dependent on the crash.<br>

</div></div></blockquote><div><br></div><div>The Twisted Scheduler considers a task dependency unmet if the task raised an error, and currently the ZMQ scheduler has no sense of error/success, so it works the other way, but can easily be changed if I add the ok/error status to the msg header (I should probably do this).  I think this is a fairly reasonable use case to have a switch on failure/success, and it would actually get you the callbacks you mention:</div>

<div><br></div><div>msg_id = client.apply(job1)</div><div>client.apply(cleanup, follow_failure=msg_id)</div><div>client.apply(job2, after_success=msg_id)</div><div>client.apply(job3, after_all=msg_id)</div><div><br></div>

<div>With this:</div><div>    iff job1 fails: cleanup will be run *in the same place* as job1</div><div>    iff job1 succeeds: job2 will be run somewhere</div><div>    when job1 finishes: job3 will be run somewhere, regardless of job1&#39;s status</div>

<div><br></div><div>Satrajit: Does that sound adequate?</div><div>Brian: Does that sound too complex?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class="gmail_quote"><div>
 </div><div class="im"><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
<div>&gt; * callback support for node: node_started_cb, node_finished_cb<br>
<br>
</div>I am not sure we could support this, because once you create the DAG<br>
and send it to the scheduler, the tasks are out of your local Python<br>
session.  IOW, there is really no place to call such callbacks.<br></blockquote></div><div><br>i&#39;ll have to think about this one a little more. one use case for this is reporting where things stand within the  execution graph (perhaps the scheduler can report this, although now, i&#39;m back to polling instead of being called back.)<br>


 </div><div class="im"><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
<div>&gt; * support for nodes themselves being DAGs <br></div></blockquote></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex"><div>... <br></div>


</blockquote><div class="im"><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex"><div>
</div>I think for the node is a DAG case, we would just flatten that at<br>
submission time.  IOW, apply the transformation:<br>
<br>
A DAG of nodes, each of which may be a DAG =&gt; A DAG of node.<br>
<br>
Would this work?<br></blockquote></div><div><br>this would work, i think we have a slightly more complicated case of this implemented in nipype, but perhaps i need to think about it again. our case is like a maptask, where the same thing operates on a list of inputs and then we collate the outputs back. but as a general purpose mechanism, you should not worry about this use case now.<br>

</div></div></blockquote><div><br></div><div>A DAG-node is really the same has having the root(s) of a sub-DAG have the dependencies of the DAG-node, and anything that would depend on the DAG-node actually depends on any|all of the termini of the sub-DAG, no?</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote"><div>
 </div><div class="im"><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
<div>Yes, it does make sense to support DRMAA in ipcluster.  Once Min&#39;s<br></div>
stuff has been merged into master, we will begin to get it working<br>
with the batch systems again.<br></blockquote></div><div><br>great.<br><br>cheers,<br><br>satra<br><br></div></div>
<br>_______________________________________________<br>
IPython-dev mailing list<br>
<a href="mailto:IPython-dev@scipy.org">IPython-dev@scipy.org</a><br>
<a href="http://mail.scipy.org/mailman/listinfo/ipython-dev" target="_blank">http://mail.scipy.org/mailman/listinfo/ipython-dev</a><br>
<br></blockquote></div><br>