<br><br><div class="gmail_quote">On Wed, Sep 14, 2011 at 14:32, Dharhas Pothina <span dir="ltr">&lt;<a href="mailto:Dharhas.Pothina@twdb.state.tx.us">Dharhas.Pothina@twdb.state.tx.us</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">


  

  
  <div style="margin-top:4px;line-height:normal;font-variant:normal;margin-right:4px;margin-bottom:1px;margin-left:4px">
<br>      
    <p style="margin-top:0;margin-bottom:0">
      <font size="3" face="Lucida Grande">It may be more a case of differing nomenclature. To me a profile/profile name is something you set up once and applies to a class of things. i.e within SGE we have a parallel environment (or profile) called mpich and when we tell any script to use that particular parallel environment it sets things up a certain way. When you actually submit a job to SGE using that profile it gets a jobid which is what you can use to track or kill the actual job.</font> </p>

</div></blockquote><div><br></div><div>There is not a 1:1 correspondence of jobid to IPython cluster.  The controller may or may not be run via SGE, and you can have an arbitrary number of SGE jobs corresponding to engines.  Only in the case of non-SGE controller and single group of SGE engines is there 1 jobid per cluster.  SGE Controller+engines will have two job IDs, and if you add/remove engines over time, there can be 0-many job IDs associated with the cluster, and the active job ids are a function of time.  The *only* constant is the controller (again, which may or may not have a job id at all), and which will ultimately become resumable, so even its job id / pid cannot be assumed to be constant.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div style="margin-top:4px;line-height:normal;font-variant:normal;margin-right:4px;margin-bottom:1px;margin-left:4px">

<p style="margin-top:0;margin-bottom:0">    </p>
<br>      
    <p style="margin-top:0;margin-bottom:0">
      <font size="3" face="Lucida Grande">The 1-1 correspondence makes sense if you plan to have the ipcluster running continuously of a certain number of cluster nodes and keep connecting and disconnecting with local ipython clients.</font></p>

</div></blockquote><div><br></div><div>In fact, it makes sense for *all* cases that don&#39;t include running multiple simultaneous clusters with identical configuration.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div style="margin-top:4px;line-height:normal;font-variant:normal;margin-right:4px;margin-bottom:1px;margin-left:4px"><br>      
    <p style="margin-top:0;margin-bottom:0">
      <font size="3" face="Lucida Grande">To me the use case that makes sense is different. We submit a job to run on a certain number of nodes and after the job s completed those the nodes are released for other non ipython runs like our fortran hydro models. In that case the &#39;profile&#39; is what tells it how to submit a job to the sge queue etc and the job-id or controller-id is what we use to run the job/kill the job etc. Maybe --controller-id flag could be an optional parameter.</font></p>

</div></blockquote><div><br></div><div>There is a bit of mismatch in design goals in IPython profiles, due to their evolution.  The entire profile system in IPython was developed for the purpose of consolidating the information about configuring and connecting to a single cluster instance (including repeated runs, but never simultaneous).  This has been expanded and adopted by IPython as a whole, for managing configurations and runtime files, and has come to mean something slightly different as a result.  The parallel code has not been changed to consider these ideas yet.</div>

<div><br></div><div>I think the restriction that a cluster is a singleton per-profile will remain, unless you specify a new cluster_id *for each additional cluster*.  The benefits of this assumption are just far too great to not make it by default.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div style="margin-top:4px;line-height:normal;font-variant:normal;margin-right:4px;margin-bottom:1px;margin-left:4px">

<p style="margin-top:0;margin-bottom:0">    </p>
<br>      
    <p style="margin-top:0;margin-bottom:0">
      <font size="3" face="Lucida Grande">Another feature request is some way of knowing when the engines have all started up, depending on how busy the cluster SGE queue is the engine may not start up immediately. Right now, I&#39;m using a while loop that checks for the presence of the json file every 5 seconds. This works but seem inelegant.</font></p>

</div></blockquote><div><br></div><div>Yes, this would certainly be useful.  Right now, there is no notion of a queued state for jobs, but it could conceivably be added (pull requests are welcome!).  I should note that polling for the JSON file only detects when the *controller* is running, and has nothing to do with engines.  Engines do not necessarily write any files.</div>

<div><br></div><div>SGE (as with all batch systems) already provides you with queue monitoring tools - there&#39;s no need to poll the filesystem, as you can just use qstat directly to see when engines have started.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div style="margin-top:4px;line-height:normal;font-variant:normal;margin-right:4px;margin-bottom:1px;margin-left:4px">

<p style="margin-top:0;margin-bottom:0">    </p>
<br>      
    <p style="margin-top:0;margin-bottom:0">
      <font size="3" face="Lucida Grande">let me know if this use case makes sense or if I&#39;m missing something in the way these features were designed to be used.</font></p></div></blockquote><div><br></div><div>I think this use case does make sense, but we are just running into the issue that ipcluster is not meant to solve every problem, and the false notion that ipcluster is the only (or even primary) way to start IPython. In fact, I think it is used far more often than it should be.  I think people wrongly assume that ipcluster is the only way to start an IPython cluster, when it is in fact only a convenient way to start *simple* clusters.  </div>

<div><br></div><div>ipcluster is intended as an extremely basic launcher.  Its purpose is to handle the simple cases of starting zero-to-one controller and one-to-many engines in various environments.  *All it does* is start these other processes with a bit of abstraction regarding what starting/stopping means with respect to qsub, mpi, etc.  It was never meant to handle every case, and never will.  Writing your own scripts, that call ipengine/ipcontroller directly, to submit via qsub will frequently be a better solution than ipcluster.</div>

<div><br></div><div>It is not at all difficult to replicate the subset of what ipcluster does for your environment with *much* simpler code that would ultimately be more useful and controllable for you.</div><div><br></div>

<div>-MinRK</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div style="margin-top:4px;line-height:normal;font-variant:normal;margin-right:4px;margin-bottom:1px;margin-left:4px">

<p style="margin-top:0;margin-bottom:0">    </p>
<br>      
    <p style="margin-top:0;margin-bottom:0">
      <font size="3" face="Lucida Grande">- dharhas</font>    </p>
<br>      
    <p style="margin-top:0;margin-bottom:0">
      <br>
      &gt;&gt;&gt; MinRK &lt;<a href="mailto:benjaminrk@gmail.com" target="_blank">benjaminrk@gmail.com</a>&gt; 9/14/2011 2:12 PM &gt;&gt;&gt;<br><br><br>    </p><div><div></div><div class="h5">
    <div class="gmail_quote">
      <p style="margin-top:0;margin-bottom:0">
        On Wed, Sep 14, 2011 at 11:13, Fernando Perez <span dir="ltr">&lt;<a href="mailto:fperez.net@gmail.com" target="_blank">fperez.net@gmail.com</a>&gt;</span> wrote:<br>      </p>
      <blockquote class="gmail_quote" style="margin-top:0;border-left:1px #ccc solid;margin-right:0;padding-left:0;margin-bottom:0;margin-left:0">
        <p style="margin-top:0;margin-bottom:0">
          Hi Dharhas,<br><br>On Wed, Sep 14, 2011 at 6:59 AM, Dharhas Pothina<br>        </p>
        <div>
          <p style="margin-top:0;margin-bottom:0">
            &lt;<a href="mailto:Dharhas.Pothina@twdb.state.tx.us" target="_blank">Dharhas.Pothina@twdb.state.tx.us</a>&gt; wrote:<br>          </p>
        </div>
        <div>
          <p style="margin-top:0;margin-bottom:0">
            &gt; I ended up writing a script that connected to the cluster and made a copy of<br>&gt; an already created profile with a new unique name, started ipcluster, waited<br>&gt; till the json file was created and then retrieved the json file for use in a<br>

&gt; local client, runs my script and then cleans up afterwards.<br>&gt;<br>&gt; This seems to be working fairly well except when the local script exits<br>&gt; because of an error. In that case, I need to log in and stop the engines,<br>

&gt; clean up files etc manually.<br><br>          </p>
        </div>
        <p style="margin-top:0;margin-bottom:0">
          OK. We probably should remove the assumption of a 1 to 1 mapping<br>between profiles and running clusters, but that will require a fair<br>bit of reorganization of code that uses that assumption, so I&#39;m glad<br>

you found a solution for now.<br>        </p>
      </blockquote>
      <div>
        <p style="margin-top:0;margin-bottom:0">
          <br>
                  </p>
      </div>
      <div>
        <p style="margin-top:0;margin-bottom:0">
          Yes, it&#39;s a pretty big deal that the only thing engines and clients need to know to connect to a cluster is the profile name. That is lost entirely if we allow multiple clusters with a single profile, since profile name becomes ambiguous. We would then need to add a second layer of specification for which controller to use within a given profile, e.g.:        </p>


      </div>
      <div>
        <p style="margin-top:0;margin-bottom:0">
          <br>
                  </p>
      </div>
      <div>
        <p style="margin-top:0;margin-bottom:0">
          ipengine --profile=mysge --controller-id=12345        </p>
      </div>
      <div>
        <p style="margin-top:0;margin-bottom:0">
          <br>
                  </p>
      </div>
      <div>
        <p style="margin-top:0;margin-bottom:0">
          I think I could add support for exactly this without much code change at all, though.        </p>
      </div>
      <div>
        <p style="margin-top:0;margin-bottom:0">
          <br>
                  </p>
      </div>
      <div>
        <p style="margin-top:0;margin-bottom:0">
          Feature Request opened on GitHub: <a href="https://github.com/ipython/ipython/issues/794" target="_blank">https://github.com/ipython/ipython/issues/794</a>        </p>
      </div>
      <div>
<br>          
      </div>
      <blockquote class="gmail_quote" style="margin-top:0;border-left:1px #ccc solid;margin-right:0;padding-left:0;margin-bottom:0;margin-left:0">
        <p style="margin-top:0;margin-bottom:0">
          <br>
          Cheers,<br><font color="#888888"><br style="color:#888888">f<br style="color:#888888"></font>        </p>
      </blockquote>
    </div>
    <p style="margin-top:0;margin-bottom:0">
      <br>
    </p>
  </div></div></div>

<br>_______________________________________________<br>
IPython-User mailing list<br>
<a href="mailto:IPython-User@scipy.org">IPython-User@scipy.org</a><br>
<a href="http://mail.scipy.org/mailman/listinfo/ipython-user" target="_blank">http://mail.scipy.org/mailman/listinfo/ipython-user</a><br>
<br></blockquote></div><br>