Repast Simphony: Standalone display quirkiness

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….)

Repast Simphony: Sample batch_params.xml

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.

Repast Simphony: Batch file to enable batch runs

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 

Build a Repast installer that doesn’t share your source code

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.

Repast Simphony: FileNotFoundException upon saving model scenario

After creating new display items in the Repast runtime environment (a Data Set and a Chart) , I wanted to save the scenario so that Repast would remember to create these display items each time I ran the model.  (When you click the Save Button/diskette in the runtime environment, the display items currently in the Scenario Tree are saved and then will always automatically load with the model — it saves a lot of work in recreating displays.)

But each time I clicked the diskette to save the model, I got this file not found exception:

2010/07/28 15:27:59,640: Error while saving scenario
java.io.FileNotFoundException: C:\Program 
Files\RepastSimphony-1.2.0\workspace\yourModelName\yourModelName.rs\styles\.svn\all-wcprops (Access is denied)
at java.io.FileOutputStream.open(Native Method)
at java.io.FileOutputStream.(Unknown Source)
at java.io.FileOutputStream.(Unknown Source)
at repast.simphony.util.FileUtils.copyDirs(FileUtils.java:88)
at repast.simphony.util.FileUtils.copyDirs(FileUtils.java:81)
at repast.simphony.ui.RSApplication.doSave(RSApplication.java:420)
at repast.simphony.ui.RSApplication.save(RSApplication.java:376)
at repast.simphony.ui.action.SaveModel.actionPerformed(SaveModel.java:17)
(and so on)

And then suddenly my /yourModelName.rs/ folder (the one containing model.score) would be suddenly, horribly, inexplicably gone — which meant that running the model again was impossible until I reinstated it.  (Repast was renaming the directory to /yourModelName.rs.bak/ and renaming any existing .bak files to .bak0, .bak1, and so on.)

At first I thought that the problem was a case of Repast moving /yourModelName.rs/ in expectation of generating a new version from my current runtime settings in its place, and then trying to copy previous data from the old filename (that no longer existed) rather than the renamed .bak version, but this is actually not what was happening.  The FileNotFoundException wasn’t actually indicating a missing file (although by the time I got the exception, that file was indeed missing on that path)… it was indicating an unwriteable file.

In fact, for me, this was a Subversion-related problem.  I was able to fix it by unsetting the read-only attributes on my .svn folders and their files and subfolders (both /yourModelName.rs/.svn and /yourModelName.rs/styles/.svn).  I unchecked all the read-only checkboxes in the properties of those files.  And then, magically, I could save the model scenario.  Repast generated scenario.xml without any trouble once the .svn directory properties were changed.

I am unsure why this happened.  Repast hasn’t complained about the other .svn directories in the project (which are all still marked as read-only).  Other team members have not had this issue.  I was able to successfully save scenarios earlier this year.  But in any event, lesson learned and solution found.