During standalone model installation, one user received an error that read “This directory cannot be written!” upon attempting to install the model into C:/Program Files/modelName.  Creating the modelName directory directly in Explorer didn’t help, and neither did giving TrustedInstaller.exe (which is built into Vista) full permissions.

It seems like this may be an IzPack compatibility with Vista/Windows 7 issue (no guarantee, as I haven’t yet personally experienced or fixed this issue).   (Repast uses IzPack to create the standalone .jar for model installation.)  I haven’t been able to verify this myself yet, but am hoping the clue may be useful to others.  It may be possible to overcome this error through settings within IzPack, a solution that I am only guessing is possible on the basis of a non-Repast thread at Stack Overflow — in that thread, the user solved the problem by making the installer ask for appropriate privilege escalation.

Drawing on that thread, apparently the issue here is a change in how post-Windows XP versions of Windows do administrator privileges.  In Visa and Windows 7, you can be logged in “as an administrator”, but that doesn’t actually mean anything unless the UI/UAC confirms it (in reality on those OSs, running “as an admin” means you are actually running as a privileged user who can elevate to admin under appropriate circumstances).  As a result, during install, the installer needs to know to pop up the UAC dialogue that queries the user whether s/he is okay with elevating for this task.  The default Repast installer doesn’t allow for this.

You can also avoid this issue on Vista/Windows 7 by installing the model into a subdirectory of My Documents, should that be a possibility.

Sometimes, although the model installs successfully from the standalone installer setup.jar file, the displays refuse to behave correctly. We observed the following odd behaviors in standalone runtime models on some Windows machines:

• Charts (data visualizations) and Displays (geography objects) did not initially render upon model initialization (“initialize” or “play” seemed to work, but nothing was displayed in the main panel).
• Charts were only displayed when the model was paused and then restarted.
• When paused and restarted, the model would display two charts — one chart completely blank, and the other showing the expected data.  Every single chart would be doubled.
• No matter what, the GIS display would not render.

To a large extent, this behavior seemed to be determined by whether the machine running the standalone model also already had the Repast development environment installed.  If the machine had the development environment installed, the displays almost always showed up properly; if the machine had only a Java JRE and not Repast, the displays were missing or repeated (and the GIS map wouldn’t appear at all).

We asked at the Repast-interest listserv in case someone knew of a solution (or if not, to alert the developers of a potentially new bug).  Nick Collier suggested on the basis of the missing GIS map display that the problem may be that Repast requires the Java Advanced Imaging libraries to be installed. He linked the Sun website’s 1.1.2 release, but the installer didn’t play well with the first test machine.  Instructions for installing Java Advanced Imaging libraries from elsewhere on the internet resulted in total success, however!  And that was that, problem solved.

Two Repast lessons here:

1. Make sure to test standalone installations on machines without the Repast development environment installed.
2. If you have odd display issues using Repast, make sure that Java Advanced Imaging (JAI) is installed, with .jars to jre/lib/ext and .dlls to jre/bin.

NOTE: The model would produce the error below, but only after the model was paused and then restarted (without pausing and restarting, no charts were created that could even generate an error):

2010/08/16 11:19:55,510: Error while creating displays
java.lang.IllegalArgumentException: Duplicate AttributeTypes DefaultAttributeType [name=__sele_cted__ , type=class java.lang.Boolean , nillable=true, min=1, max=1]
at org.geotools.feature.FeatureTypeBuilder.check(FeatureTypeBuilder.java:600)
at org.geotools.feature.FeatureTypeBuilder.addType(FeatureTypeBuilder.java:347)
at org.geotools.feature.FeatureTypeBuilder.addTypes(FeatureTypeBuilder.java:327)
at repast.simphony.space.gis.FeatureAgentFactory.getFeatureType(FeatureAgentFactory.java:169)
...

(This problem and its solution are also documented in the Repast-interest thread; they are repeated here for more recorded detail in the hope that more Googleable buzzwords might bring you to a solution faster….)

The skeleton version called batch_params.xml in the batch folder of the Repast project folder is not a good example of what the final format should look like. Similarly, the batch parameters tutorial, while very good and offering plenty of line-by-line examples, does not give a complete example of what a batch_params.xml file should look like, either.

In writing my batch_params.xml file, the file available here helped:

C:\Program Files\RepastSimphony-1.2.0\eclipse\plugins\repast.simphony.batch_1.2.0\models\test_batch_params2.xml

So you don’t have to go searching for it yourself, the content is:

<?xml version="1.0" ?>
<sweep runs="2" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="batch_params.xsd">
    <parameter name="double_const" type="constant" constant_type="number" value="4.0" />
    <parameter name="long_const" type="constant" constant_type="number" value="11L" />
    <parameter name="string_const" type="constant" constant_type="string" value="hello cormac" />
    <parameter name="boolean_const" type="constant" constant_type="boolean" value="false" />
    <parameter name="long_param" type="number" start="1L" end="3" step="1">
       <parameter name="float_param" type="number" start=".8f" end="1.0f" step=".1f">
          <parameter name="string_param" type="list" value_type="String" values="foo bar">
              <parameter name="randomSeed" type="list" value_type="int" values="1 2" />
          </parameter>
       </parameter>
    </parameter>
</sweep>

Christof Zellweger, a postgraduate student at the University of Melbourne, also notes that the batch parameters XSD describing the schema of the batch_params.xml is in the plugins folder of the core Repast module. The schema file is likely to be located here: /path/to/repast/installation/eclipse/plugins/repast.simphony.batch_/models/batch_params.xsd.

—
Updated 2012.07.28.

In trying to do batch runs, I was following this listserv post.  It is a fantastic post!  However, the batch file has a typo.

The batch file should be:

@echo off
rem The version of Repast Simphony being used.
set VERSION=1.2.0
rem The installed path of Repast. Quotes may be necessary if there is a space character in the path.
set REPAST="C:\Program Files\RepastSimphony-1.2.0"
rem The installed path of Eclipse. Quotes may be necessary if there is a space character in the path.
set ECLIPSE="C:\Program Files\RepastSimphony-1.2.0\eclipse"
rem The plugins path of Eclipse.
set PLUGINS=%ECLIPSE%\plugins
rem The workspace containing the Repast model.
set WORKSPACE=%REPAST%\workspace
rem The name of the model. This might be case-sensitive. This is the name of your package. It should 
rem be the package at the top of all your .java files and match the "package" listed in your model.score 
rem file (when viewed as a text file).
set MODELNAME=myPackage
rem The folder of the model. This might be case-sensitive. This is the base folder of your project in 
rem the file system.
set MODELFOLDER=%WORKSPACE%\myProjectFolder
rem The file containing the batch parameters. For some additional information, see Repast documentation 
rem of batch parameters at http://repast.sourceforge.net/docs/reference/SIM/Batch%20Parameters.html and/or 
rem an example batch_params.xml file at http://www.pamelatoman.net/blog/2010/08/sample-batchparamsxml/.
set BATCHPARAMS=%MODELFOLDER%\batch\batch_params.xml

rem Execute in batch mode.
java -cp %PLUGINS%\repast.simphony.batch_%VERSION%\bin;%PLUGINS%\repast.simphony.runtime_%VERSION%\lib\*;
%PLUGINS%\repast.simphony.core_%VERSION%\lib\*;%PLUGINS%\repast.simphony.core_%VERSION%\bin;
%PLUGINS%\repast.simphony.bin_and_src_%VERSION%\*;%PLUGINS%\repast.simphony.score.runtime_%VERSION%\lib\*;
%PLUGINS%\repast.simphony.data_%VERSION%\lib\*;
%MODELFOLDER%\bin repast.simphony.batch.BatchMain -params %BATCHPARAMS% %MODELFOLDER%\%MODELNAME%.rs 

You can run this batch file from anywhere on the filesystem.

This came to light after fighting for significantly too much time with a RuntimeException that told me it “couldn’t find classes using supplied class loader”. It was telling me that it couldn’t find myPackage.ClassName on the very same path that had the compiled code! All the pointers toward this sort of error pointed to the model.score file — but model.score was not the problem here. The problem was that the model’s actual bin had not been added to the classpath.

For posterity, the exception I was getting was:

java.lang.RuntimeException: Couldn't find classes using supplied class loader: 
myPackage.ClassName on path: correct\path\to\project\bin
at repast.simphony.scenario.ScenarioLoader.getAgentClasses(ScenarioLoader.java:274)
at repast.simphony.scenario.ScenarioLoader.load(ScenarioLoader.java:160)
at repast.simphony.batch.BatchRunner.run(BatchRunner.java:87)
at repast.simphony.batch.BatchMain.run(BatchMain.java:119)
at repast.simphony.batch.BatchMain.main(BatchMain.java:141)
usage: repast.simphony.batch.BatchMain [options] target
Where target is the path to a scenario file or the fully qualified name of a class 
that implements repast.simphony.batch.BatchScenarioCreator.
-help            print this message
-interactive     specifies if the batch mode is interactive
-opt <file>      use optimizable parameter sweeper with given optimizing properties file
-params <file>   use given parameter sweep file 

By default, a model installer built using Repast’s Build Installer functionality will also include your raw source code (not just the bytecode).  If you do not want your .java files to be bundled with the model installer, you can change this in the project’s installer/installation_components.xml file.  Remove or comment out these lines from that file (near the bottom):

<pack name="Sources" required="no">
<description>The model source code</description>
<file src="repast.simphony.bin_and_src_$REPAST_VERSION/temp/src" targetdir="$INSTALL_PATH/yourModelName"/>
</pack>

After you create the new installer and install the model, the directories of the standalone model should no longer contain your source code.  Those directories will only contain the .class files.  (Of course, it’s still possible for the user to decompile the .class files back into .java files, but at least removing the raw .java files sends the signal and requires some actual work to get the code on any unscrupulous users’ parts. Use an obfuscator to avoid decompilation if you’re worried.)

Repast uses IzPack to build the software installer for its models.  Inside your project’s /installer directory are the .xml and other files that IzPack uses.