You can use the report file produced by a heatbugsPlus run
as an input file, to use the same parameters as in a previous run:
  ./heatbugsPlus -DIF=report &
You can do that with report files from GUI runs or batch runs.

You can run in batch mode, setting various parameters on the
command line as follows:
  ./heatbugsPlus --batch -DnumBugs=30 -DstopT=300 &
or you can have parameters read from a file
  ./heatbugsPlus --batch -DIF=report1 &
and combine the two:
  ./heatbugsPlus --batch -DIF=report1 -DnumBugs=30 &
to override the numBugs parameter from the report1 input file.

Note: In the above commands, you proceed with heatbugsPlus with
   ./ (dot-slash) to indicated that you want to run the version
   in the current directory.  If you are running a version
   that is located in some other directory, substitute the
   appropriate path before the heatbugsPlus program name.

To see all settable parameters, 
  heatbugsPlus -Dh --batch
(currently it will also run a small batch job and produce
a report file for it).

The predefined parameters, i.e., not part of heatbugs itself,
including full name, alias and default value:

reportFileName (RF) = report
    file to which report will be written    
reportFileNameSuffix (RN) = 
    appended to reportFileName, after a dot (.)
reportFrequency (RF) = 1
    frequency averages will be written to report
outputDirName (OD) = .
    directory into which report will be written.
    default is the directory in which heatbugsPlus is run.
    NOTE: the directory must exist.
stopT (T) = 4
    number of steps to run in batchmode.
seed (S) = 0
    RNG seed.  Default (0) means generate a new one
    from clock time and process number.
inputFileName (IF) = rparameters.in
    file from which parameters were read.
    (this is ignore when in an input file!)
rDebug (D) = 0
    sets rDebug flag (not currenlty used...could be used
    to control debugging messages).

Note: if you want to change these non-Heatbugs parameters
in GUI mode (usually the only ones you would want to change
are seed the rDebug and reportFrequency), you must
1) MB3 the Heatbug button in the top-left of the 
   Parameters probe.  That will bring up a new probe into
   parameters (dismiss the first one by pressing the button
   with the red icon in the top right of the probe).
2) In the top right of the new probe there is, to the right
   of the red circle-like icon, a little icon with green
   boxes connected by a line.  Press this, and the probe
   will expand to include variables (and methods) in the
   superclass.  You will see seed, etc, there.  
   The heatbugs parameters are still there...just use
   the slider on the right to look at the bottom of the probe.
   You can also dismiss the original Parameters probe by
   MB1 clicking the red button in its upper right.
3) As with all input probes, be sure to press RETURN key
   after you change a value for a parameter.

See this UM-ExpTools-4 page for information about the RParameters and RParameter objects and utility macros which are used in this application. Those provide:

You can use the classes in /users/rlr/SwarmStuff/CSCS-Demos/UM-ExpTools4 in any Swarm program. To get an idea of what you would have to change, here is a list of the main changes required to go from the standard heatbugs to the UM-HeatbugsPlus version:

1. Makefile has changes to:
   - add the new Parameters object
   - link to /users/rlr/SwarmStuff/CSCS-Demos/UM-ExpTools4 as an application lib.
   - save a dated tar file, in a Saves directory.

2. main.m has changes to:
   - import RParametersArgs.h, and pass it to the
     initSwarmARguments() function
   - changed message to buildObjects to include argc and argv
   - send message to Parameters to set ProgName and ProgVersion
   - send message to Parameters to close its report file
   - send progname name and version to Parameters object

3. Add Parameter object, subclass of RParameters object.
   All parameters are stored here; add instance variable 'parameters'
   in Batch and Observer; ModelSwarm points to those.
   Utility macros defined in RParmaters.h to access the parameters.
   Note that RParameters provides a number of built in parameters.

3. HeatbugBatchSwarm
   - createBegin creates the basic Parameters object.
   - buildObjects accepts the argc and argv variables
     sends the initParameters message to Parameters followed
     by the processCmdLineArgC:ArgV message.
   - unhappyGraph now writes to the Parameters report file,
     at the reportFrequency, as controlled by the Model -stepReport.
   - Parameter variable stopT is used to control stopping the run.

4. HeatbugObserverSwarm
   - createBegin creates the basic Parameters object
     sets up an EZBin with a variable numBins
     add method/probe for writeEZBinToFile
     add method/probe for addHeatbug
     add method/probe for createHeatbug
   - buildObjects accepts the argc and argv variables
     sends the initParameters message to Parameters followed
     by the processCmdLineArgC:ArgV message.
     add second line to the unhappyGraph, just to show how.
     add a separate BLTGraph, with some Averages, to show how.
     add the EZBin
   - add actions to update the averagers, graphs, EZBin.

5. HeatbugModelSwarm 
   - it no longer has the parameter variables, just a single
     parameters variable pointing to that new object.
   - it is no longer probed
   - add a createHeatbug method, use it in the create loop.
     this method also stores the new parameters in the bugs.
   - send evaporation rate on to the heatspace.
   - sets up its own unHappinessAverager, used by its
     own stepReport method.
   ==> This a bit different from the basic Swarm philosophy,
       in that the Model object itself is responsible for the
       report file.   I consider at least some reports to be
       an integral part of a model, not the Observers.