You are looking at the HTML representation of the XML format.
HTML is good for debugging, but is unsuitable for application use.
Specify the format parameter to change the output format.
To see the non HTML representation of the XML format, set format=xml.
See the complete documentation, or API help for more information.
<?xml version="1.0"?>
<api>
  <query-continue>
    <allpages gapcontinue="Symmetry_Breaking_and_Motility" />
  </query-continue>
  <query>
    <pages>
      <page pageid="10" ns="0" title="Running comet on a cluster">
        <revisions>
          <rev contentformat="text/x-wiki" contentmodel="wikitext" xml:space="preserve">We highly recommend running 'comet' on a cluster of machines, rather than just one.  The program takes some time to run (an hour or two for early events like symmetry breaking; overnight if you want to look at the later motility, pulsatile motion etc.)  Running the program concurrently on at least 5 machines (I used 9) lets you efficiently test the effect of changing one parameter through a range of values.  You can set it going then come back the following day and have the whole thing laid out for you.  I've found this very useful, and have included a set of scripts to automate the process, including automatically generating the montage of images seen in the robustness section so you can quickly scan the effect of varying the parameter.  


I recommend putting a default '''cometparams.ini''' into a main directory for the data e.g. '''~/runs'''.  In that directory run the '''varyset''' script (included with the source):
 varyset &lt;parameter&gt; &lt;startval&gt; &lt;endval&gt; &lt;number of steps&gt;
This will create a subdirectory within '''runs''' that contains subdirectories numbered 1,2,3,etc. each containing a version of the '''cometparams.ini''' file with the &lt;parameter&gt; value varying in linear steps between &lt;startval&gt; and &lt;endval&gt;.  It will also add information to run the individual comet jobs into ~/joblist.  

If you have access to a cluster with a working job control system, you might want to use that.  I had trouble with the job control system on the cluster I was using, and ended up writing my own:

On the head node, I have the 
 startnewjobs
script running as a cron job every 15 minutes.  This checks to see if the worker nodes are idle (5 min load average below a certain threshold) and starts the next job if they are.

The script jobstat will list the progress, e.g.
 mark@biostar01:/cluster/comet$ jobstat
 
   Machine  1mld  5mld       ID      R             Frame
        b1  3.69  3.15 05-14-09_0017 1 |T   16|S 109/700 *
        b2  3.39  2.93 05-14-09_0017 8 |T   15|S 116/700 *
        b3  3.38  2.87 05-14-09_0017 4 |T   15|S 112/700 *
        b4  3.55  3.07 05-14-09_0017 6 |T   15|S 114/700 *
 
 0 nodes free
 4 jobs waiting



If you don't have access to a cluster, there is a single computer version of startnewjobs
 startjobsloop
which will check ~/joblist for new jobs and run them sequentially.


The script
 makematrix
pulls together an image matrix (as seen in the robustness section) to summarize the effect of varying the parameter.  The directory name, time, computer and main section of the competparams.ini file are converted into an image and included on the left hand side of the summary, to keep track of the details of the run.</rev>
        </revisions>
      </page>
      <page pageid="3" ns="0" title="Running the program">
        <revisions>
          <rev contentformat="text/x-wiki" contentmodel="wikitext" xml:space="preserve">===Command line syntax===

The program expects to be run from a new directory containing a copy of the control file cometparams.ini, an example of which is included in the source code and explained in detail below.  Typing `comet' without any parameters returns the command line syntax.

For a new simulation setup the parameter file 'cometparams.ini'
in current directory and type:
 comet &lt;numThreads&gt;
where &lt;numThreads&gt; is the number of CPUs to use
e.g. typing `comet 4' will start a new run using 4 simultaneous threads and parameters read from the cometparams.ini control file.

To process an existing dataset type:
 comet &lt;command&gt; &lt;frame range&gt;
where &lt;command&gt; is 'post' to write bitmap images,
'vtk' to write 3D images or 
'view' to enter 3D interactive mode.
e.g.:
 comet post 1:300 
writes bitmaps for frame 1--300, and
 comet view 300:300 
enters 3D interactive mode for frame 300
(the range '0:0' can be used to process all frames).</rev>
        </revisions>
      </page>
    </pages>
  </query>
</api>