repast-developer

[Repast-developer] Bug reports

[Laszlo G. <gu...@la...>]

Hi,

Here I have two issues.

The first of them is relatively easy. The ParameterReader seems to reset
the random seed, unless it is explicitly set in the parameter file. It may
get annoying, especially for users of SimpleModel, who usually have a nice
pre-set random seed. What happens is that when they go from the GUI model
to the batch one, it breaks down out of their control.
See the ParameterReader.zip in the attachment.

This problem must be relatively easy to solve. The second issue is more
serious. I am not sure whether it really deserves to be called a bug, or it
is rather something users should be warned of. It is about how using
HashMap's, HashSet's and the like might prevent model results from being
replicable.

It is funny how long this went unnoticed [or at least, I've never heard of 
it].
Then, it's even funnier that within a week I came across three distinct 
examples.
One using the network library, the other working with multiple occupancy
spaces. The last one was in my own code, so I had no choice, but to nail
it down... ;-)

Anyhow, the problem is demonstrated in the second attachment: HashMapTest.zip.
The uncommented hashCode() method immediately solves it, however.
As for the reasons, the docs of java.lang.Object suggest that unless other,
more meaningful value is provided, JVMs would use the _memory_address_
of that object. Not really reproducible, indeed.

Fortunately, in most cases it is easy to providea  more meaningful 
identification.
If the keys stored in the Hash are completely within Repast's control, 
everything
is alright. However, in other cases, the keys might come from the user. I 
don't quite
know what to do in those cases, except for putting out a warning. It might 
be quite
troublesome, however, to nail down all affected classes in Repast that 
users should
be warned of.

What do you think?

All the best,

Gulya

[Repast-developer] Live Repast Class and Developer's Meetings!

[North, M. <no...@an...>]

As you may know the University of Chicago and Argonne National =
Laboratory
are co-hosting a conference on agent-based modeling and simulation on
October 11 and 12, 2002 in Chicago, IL USA.  What you may not know is =
that
we will also be offering a Toolkit Developer's meeting on October 7, =
2002, a
live, hands-on Repast training class on October 8 and 9, 2002 and a =
Methods,
Toolkits, and Techniques Day on 10, 2002.  The planning schedule for =
the
class and developer's meetings are as follows:
=20
Monday, October 7, 2002
=20
8:30 - 8:45 a.m.            Toolkits Developer's Meeting Welcome
                                    Michael North, Argonne National
Laboratory
=20
8:45 -10:00 a.m.            Where Are We Today?
                                    Moderator: Nick Collier, University =
of
Chicago
                                    Panel:   Roger Burkhart, Deere =
Company
Tom Howe, University of Chicago
Charles Macal, Argonne National Laboratory
                                                Uri Wilensky, =
Northwestern
University
=20
10:30 - Noon                 Where Should We Be In One Year?
                                    Moderator:  Roger Burkhart, Deere
Company
Panel:   Laszlo Gulyas, Harvard University/Lor=E1nd E=F6tv=F6s =
University
Tom Howe, University of Chicago
Charles Macal, Argonne National Laboratory
Uri Wilensky, Northwestern University
=20
1:30 -3:00 p.m.             Where Should We Be In Five Years?
                                    Moderator:  Laszlo Gulyas, Harvard
University/Lor=E1nd E=F6tv=F6s University
                                    Panel:   Nick Collier, University =
of
Chicago
Roger Burkhart, Deere Company
Michael North, Argonne National Laboratory
=20
3:30 - 5:30 p.m.            How Do We Get There?
                                    Moderator:  Tom Howe, University of
Chicago
                                    Panel:   Nick Collier, University =
of
Chicago
Michael North, Argonne National Laboratory
                                                Laszlo Gulyas, Harvard
University/Lor=E1nd E=F6tv=F6s University
                                                Uri Wilensky, =
Northwestern
University
=20
Tuesday, October 8, 2002
=20
8:30 - 8:45 a.m.            Repast Tutorial Welcome
                                    David Sallach, University of =
Chicago
=20
8:45 -10:00 a.m.            Overview of Repast and Agent Simulation
                                    Tom Howe, University of Chicago
=20
10:30 - Noon                 Repast Harvard Tutorial Step 1
                                    Michael North, Argonne National
Laboratory
=20
1:30 -3:00 p.m.             Repast Harvard Tutorial Step 2
                                    Michael North, Argonne National
Laboratory
=20
3:30 - 5:30 p.m.            Repast Scheduling
                                    Nick Collier, University of Chicago
=20
Wednesday, October 9, 2002
=20
8:30 - 10:00 a.m.           Repast GUI, GIS, and Prolog+CG Libraries
                                    Tom Howe, University of Chicago
=20
10:15 -Noon                  Repast Data Collection and Charting
                                    Laszlo Gulyas, Harvard =
University/Lor=E1nd
E=F6tv=F6s University
=20
1:30 -3:00 p.m.             Repast Social Network Support
                                    Nick Collier, University of Chicago
=20
3:15 - 5:30 p.m.            Emerging Directions Including Attractor =
Systems
and Situated Activity
                                    David Sallach, University of =
Chicago
=20
Thursday, October 10, 2002
=20
9:00 - 9:15 a.m.            Methods, Toolkits, and Techniques Day =
Welcome=20
                                    Michael North, Argonne National
Laboratory
=20
9:15 - 10:30 a.m.           Swarm
                                    Roger Burkhart, Deere Company
=20
10:45 - Noon                 NetLogo
                                    Uri Wilensky, Northwestern =
University
=20
12:30 - 1:00 p.m.           Lunchtime NetLogo Collaboration =
Demonstration
                                    Uri Wilensky, Northwestern =
University
=20
1:00 - 2:15 p.m.            Ascape
                                    Miles Parker, Bios Group
=20
2:30 - 3:45 p.m.            Repast
                                    Nick Collier, University of Chicago
                                    Tom Howe, University of Chicago
=20
3:45 - 5:15 p.m.            Design & Methods
                                    Moderator & Discussant:  Michael =
North,
Argonne National Laboratory
=20
Understanding the Difference that Space Can Make: =20
Toward a Geographical Agent Modeling Environment
David O'Sullivan, Pennsylvania State University
=20
Modeling Mental Behaviours of Social Agents in Simulated Traffic World
N. Paramesh, University of New South Wales
=20
Situated Social Ecology:  An Integrated Design Hermeneutic
David L. Sallach, University of Chicago
=20
5:15 - 5:45 p.m.            Methods, Toolkits, and Techniques
                                    Moderator:  Michael North, Argonne
National Laboratory
                                    Panel:   Nick Collier, University =
of
Chicago
                                                Laszlo Gulyas, Harvard
University/Lor=E1nd E=F6tv=F6s University
                                                Uri Wilensky, =
Northwestern
University
                                                Roger Burkhart, Deere
Company
=20
To register contact either of the following people:
=20
Victor Lofgreen
University of Chicago=20
Social Science Research Computing
1155 East 60th Street
Chicago, Illinois 60637=20
Phone: 773.834.0149
Fax: 773.702.2101
=20
Kathy Ruffatto
Argonne National Laboratory
Building 900
9700 South Cass Avenue
Argonne, Illinois 60439
Phone: 630.252.5464
Fax: 630.252.9868
=20
SEATS IN THE CLASS ARE LIMITED SO SIGN UP EARLY!
=20
More information on the free conference, including the schedule and
registration forms, can be found at the conference web site:
http://www.agent2002.anl.gov/
=20
Mike
=20
Michael J. North
Software Engineer
Argonne National Laboratory
Decision and Information Sciences Division
Complex Adaptive Systems Section
=20
9700 S. Cass Avenue
Argonne, IL 60439
=20
E-mail: no...@an... <mailto:no...@an...>=20
Telephone: (630) 252-6234
Facsimile: (630) 252-6073
=20
=20

[Repast-developer] test

[Nick C. <nic...@ve...>]

test
-- 
Nick Collier 
Social Science Research Computing 
University of Chicago 
http://repast.sourceforge.net

[Repast-developer] request for repast project descriptions

[Nick C. <nic...@ve...>]

Hi all, 

I've asked this once or twice before, but the number of repast related 
projects listed on the repast project page is not representative of 
repast's actual use (I hope!!!). We had nearly 1700 downloads of 1.4
and there are quite few people on the mailing list. If even a small
portion of those are using repast, the number of projects on the project
page remains unrepresentative.

Consequently, I'd like to add to the list of projects and publications that use 
RePast on the repast web site. So, if y'all could send me a few lines 
about what you've done or are doing with repast, and your name, title, 
contact info, etc. I'd appreciate it. Also, if you have any publications
that use repast simulations, I could use an abstract as well as the
above. If you are unwilling to provide contact info that's fine as well
just a name will do.

thanks very much, 

Nick 

-- 
Nick Collier 
Social Science Research Computing 
University of Chicago 
http://repast.sourceforge.net 

[Repast-developer] branches merged and committed

[Nick C. <nic...@ve...>]

Hi,

For those of you keeping score, I've merged the our two cvs branches.
The main (or 2.0) branch now contains the current working code. Any
changes should now be committed to this branch and not to the rel-1-x
branch where work has ceased. 

The merged code compiles and all the tests pass except for a few. Those
that don't pass I'm not sure if they are valid tests. I'll investigate
more tomorrow. The demo models seem to run, but I'll need to investigate
this fully.

Nick

-- 
Nick Collier 
Social Science Research Computing 
University of Chicago 
http://repast.sourceforge.net

[Repast-developer] RFE : DisplaySurface.setPainter(Painter p) method?

[Frank B. <bl...@ps...>]

For our application, we've had to tailor the repast display quite a bit. 
 Would it be possible to put a "setPainter(Painter p)" on DisplaySurface 
in the next rev?  It's easier to work with our extension to LocalPainter 
this way.

- Frank

Re: [Repast-developer] example usage of XMLParameterReader ?

[Nick C. <nic...@ve...>]

Hi,

Here's an old test file I found. I can't guarantee it or anything like
it will work. The XMLParameterReader is sort of a failed experiment to
do batch parameter files better. I wasn't really happy with the results
and should probably remove XMLParameterReader from the distribution. 

This did work when I was writing the reader, so feel free to try it.

Nick


<?xml version="1.0"?>

<Repast:Params xmlns:Repast="http://www.src.uchicago.edu"
name="myparams">
  <Repast:ParamBlock runs="1">
    <Repast:Param name="pConst" type="const" value="3"/>
    <Repast:Param name="pStringList" type="string_list" value ="sam bill
joe george 
mary jean">
      <Repast:ParamBlock runs="2"> <!-- only need this runs if not same
as parent -->
        <Repast:Param name="pIncr2" type="incr" start=".1" end=".2"
incr=".1"/>
      </Repast:ParamBlock>
    </Repast:Param>
  </Repast:ParamBlock>
</Repast:Params>

<!--

runs: 1
 pIncr {
 start: 1
 end: 5
 incr: 1
  {
    runs: 1
    pIncr2 {
      start: .1
      end: .2
      incr: .1
    }
  }
}

      <Repast:ParamBlock runs="1">
        <Repast:Param name="MaxAge" type="list" value="1.2 3 10 12 84"/>
        <Repast:Param name="Off" type="boolean_list" value="true false
true false"/>
      </Repast:ParamBlock>
    </Repast:Param>
    <Repast:Param name="On" type="boolean_list" value="true false true
false"/>
    <Repast:Param name="RngSeed" type="const" value="1"/>
  </Repast:ParamBlock>

  <Repast:Param name="pBoolList" type="boolean_list" value ="true false
true false false"/>
      </Repast:Param>
</Repast:Params>
-->



On Mon, 2002-07-08 at 15:25, Frank Blecha wrote:
> Nick,
> 
> Is there any more doc/examples for XMLParameterReader than the class 
> itself?  I didn't see the referenced "pFile.xml" from 
> XMLParameterReader.main , and there doesn't seem to be a dtd anywhere...
> 
> - Frank
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Oh, it's good to be a geek.
> http://thinkgeek.com/sf
> _______________________________________________
> Repast-developer mailing list
> Rep...@li...
> https://lists.sourceforge.net/lists/listinfo/repast-developer
-- 
Nick Collier 
Social Science Research Computing 
University of Chicago 
http://repast.sourceforge.net

[Repast-developer] example usage of XMLParameterReader ?

[Frank B. <bl...@ps...>]

Nick,

Is there any more doc/examples for XMLParameterReader than the class 
itself?  I didn't see the referenced "pFile.xml" from 
XMLParameterReader.main , and there doesn't seem to be a dtd anywhere...

- Frank

Re: [Repast-developer] cannot compile repast

[Nick C. <nic...@ve...>]

Hi,

This is a bit odd as the java.util.collection classes have been part of
java since 1.2. So if you are using java 1.3.1 they are certainly in
there. The problem is probably with J++ whose compiler uses, I think,
1.1. At any rate, you are unlikely to find the java.util classes as a
separate jar file. They were released as com.sun.java.util, but that was
ages ago and interim step until the classes became part of 1.2. I'd
suggest using a different IDE, such as JBuilder. You can get a free
community edition of this at www.borland.com/jbuilder.

Lastly, this sort of question is more properly asked on repast-interest.

hope this helps,

nick

On Thu, 2002-06-06 at 12:13, Marco Huigen wrote:
> hi everyone, new name, new face
> 
> I am building an agent-based model and want to use repast as one of the core elements. Unfortunately I can't get it compiled, coz' I don't have some java.util classes (e.g. ArrayList and Collections). Does anyone have a jar or zip that I can use? Or is there a nice way to work arround? I use MS J++ with jdk1.3.1. under windows. I  did download  a zip-file collections, but it points to com.sun.java.util.*
> 
> Thx in advance,
> 
> 
> Marco G.A. Huigen
> 
> Centre for Environmental Studies
> Leiden University
> Einsteinweg 2
> Postbus 9518
> 2300 RA Leiden
> 
> Tel: 071-5277475
> Fax: 071-5277496
> E-mail: hu...@cm...
> E-mail: mar...@ho...
> 
> My project: http://gissrv.iend.wau.nl/~clue/philippines/intro.htm
> My Institute: http://www.leidenuniv.nl/cml
> My private site: http://www.home.zonnet.nl/marco_huigen/
> 
-- 
Nick Collier 
Social Science Research Computing 
University of Chicago 
http://repast.sourceforge.net

[Repast-developer] cannot compile repast

[Marco H. <mar...@ho...>]

hi everyone, new name, new face

I am building an agent-based model and want to use repast as one of the =
core elements. Unfortunately I can't get it compiled, coz' I don't have =
some java.util classes (e.g. ArrayList and Collections). Does anyone =
have a jar or zip that I can use? Or is there a nice way to work =
arround? I use MS J++ with jdk1.3.1. under windows. I  did download  a =
zip-file collections, but it points to com.sun.java.util.*

Thx in advance,


Marco G.A. Huigen

Centre for Environmental Studies
Leiden University
Einsteinweg 2
Postbus 9518
2300 RA Leiden

Tel: 071-5277475
Fax: 071-5277496
E-mail: hu...@cm...
E-mail: mar...@ho...

My project: http://gissrv.iend.wau.nl/~clue/philippines/intro.htm
My Institute: http://www.leidenuniv.nl/cml
My private site: http://www.home.zonnet.nl/marco_huigen/

[Repast-developer] discussion

[Thomas H. <th...@sr...>]

I read the rest of the conversation and I'm just going to say two quick things.  One, on the webstart stuff, It is really quite easy to do.  I could write a tool that would handle it.  The only challenging part is that if the app needs to write to the other computer, the jar needs to be signed.

I do have thoughts on the db stuff, but for another time.

-Tom

Re: [Repast-developer] web discussion

[Laszlo G. <gu...@la...>]

Hey, that's a great idea! Unfortunately, however, I'll be sitting in a meeting
from 11am till appr. 2pm EST. :(((

Gulya

At 03:36 PM 5/1/2002 -0500, Thomas Howe wrote:
>With version 1.4.1 now out, and version 2.0 around the corner, it seems 
>prudent to discuss the direction of repast and the issues associated with 
>that.  To this end, I propose a web discussion of all interested 
>parties.  The time will be Friday 11:30 EST.  The venue is not quite 
>definite.  If everyone who is interested has access to MS NetMeeting 
>(without voice over ip), then it will be a net meeting.  This way we will 
>have access to a shared digital whiteboard.  Otherwise, it will be on 
>irc.  Please let me know if you wish to attend and, if so, if you have 
>access to NetMeeting.
>
>Thanks,
>
>Tom Howe
>
>_______________________________________________________________
>
>Have big pipes? SourceForge.net is looking for download mirrors. We supply
>the hardware. You get the recognition. Email Us: ban...@so...
>_______________________________________________
>Repast-developer mailing list
>Rep...@li...
>https://lists.sourceforge.net/lists/listinfo/repast-developer

[Repast-developer] 2.0 ideas

[Nick C. <nic...@ve...>]

Hi,

I figure a major version release gives us the opportunity to break some
legacy code (only a little though) in order to fix somethings that are
broken. So, here's my list of things I'd like to see for 2.0 and beyond.
1. Incorporate Mike's new scheduling code. This is the whole point of
the 2.0 release after all. I'll finally get around to finishing the
testing of this next week.

2. Improve the display of network graphs. The major thing here is not to
shrink them to the screen, but provide a larger viewable area that can
be scrolled.

3. Fix the network library, in particular remove the getNode() method
from the Node interface. It is there only to ensure that gui wrapped
nodes work with the rest of the network library. Node visualization
doesn't rely on wrappers anymore so I want to clean this up as it is a
major source of really confusing bugs.

4. Serialization of models so they can be stopped and then pick up where
they leave off.

So that's it from me. Item 3 will certainly break (but not too much)
existing code and 4 is probably something for post-2.0, although I
really don't know how much work it would be.

Comments?

Nick

-- 
Nick Collier 
Social Science Research Computing 
University of Chicago 
http://repast.sourceforge.net

[Repast-developer] web discussion

[Thomas H. <th...@sr...>]

With version 1.4.1 now out, and version 2.0 around the corner, it seems prudent to discuss the direction of repast and the issues associated with that.  To this end, I propose a web discussion of all interested parties.  The time will be Friday 11:30 EST.  The venue is not quite definite.  If everyone who is interested has access to MS NetMeeting (without voice over ip), then it will be a net meeting.  This way we will have access to a shared digital whiteboard.  Otherwise, it will be on irc.  Please let me know if you wish to attend and, if so, if you have access to NetMeeting.

Thanks,

Tom Howe

Re: [Repast-developer] button name help

[Laszlo G. <gu...@fa...>]

Hi,

Maybe, I am not the one who should give advice on linguistic issues
(not in English, at least :)), but initialize sounds reasonable to me. Also
does 'create', however. After all, that's what's happening, right? It calls
buildModel(), buildSchedule() and so on, doesn't it?

Gulya

At 02:07 PM 4/22/2002 -0400, Nick Collier wrote:
>Hi,
>
>As I think I mentioned earlier I've added a button to the tool bar that
>will run all the initial code for a model but will not start the
>schedule. So, agents are created and displayed if you have a display
>surface etc. However, I'm having a trouble naming the button -- its
>somewhere between a start and setup, maybe initialize? Any suggestions?
>
>thanks,
>
>Nick
>
>--
>Nick Collier
>Social Science Research Computing
>University of Chicago
>http://repast.sourceforge.net
>
>
>_______________________________________________
>Repast-developer mailing list
>Rep...@li...
>https://lists.sourceforge.net/lists/listinfo/repast-developer

[Repast-developer] button name help

[Nick C. <nic...@ve...>]

Hi,

As I think I mentioned earlier I've added a button to the tool bar that
will run all the initial code for a model but will not start the
schedule. So, agents are created and displayed if you have a display
surface etc. However, I'm having a trouble naming the button -- its
somewhere between a start and setup, maybe initialize? Any suggestions?

thanks,

Nick

-- 
Nick Collier 
Social Science Research Computing 
University of Chicago 
http://repast.sourceforge.net

Re: [Repast-developer] mixins and aspects

[Laszlo G. <gu...@la...>]

Hi,

I am sorry for not getting back to you earlier on this.
I did read the paper in the meanwhile, however, and
I liked the idea very much. I did not have time to think
about the exact way we should use it, but I will.

Here, the questions are:

i) what exactly do we want to use it for?

ii) how can we make the usage as 'smooth' to
the user as possible?

In my experience, users are often afraid of simple casting
already, so I usually try to avoid the more advanced Java
constructs. Especially, if I expect them to use it frequently.

I am not sure about this position, however, since an
Evolver-like layer should remove all these difficulties in the long run.

Gulya


At 12:39 PM 2/16/02 -0500, Nick Collier wrote:
>Hi,
>
>I've come across a paper that describes a technique for mixing classes
>and interfaces on the fly to create new classes. This may be applicable
>to the space library and aspect oriented programming stuff we talked
>about a while ago.
>
>http://tmb.voxel.net/papers/published/2001-breuel-tools.pdf
>
>The paper itself is not particularly good, but a few nifty ideas.
>
>Nick
>
>--
>Nick Collier
>Social Science Research Computing
>University of Chicago
>http://repast.sourceforge.net
>
>
>
>_______________________________________________
>Repast-developer mailing list
>Rep...@li...
>https://lists.sourceforge.net/lists/listinfo/repast-developer

--
Laszlo Gulyas, MSc              Phone: (617) 
384-9216
Government Department   Weatherhead Center for International Affairs
Harvard University              602C Coolidge Hall
1737 Cambridge street           Cambridge, MA-02138

[Repast-developer] mixins and aspects

[Nick C. <nic...@ve...>]

Hi,

I've come across a paper that describes a technique for mixing classes
and interfaces on the fly to create new classes. This may be applicable
to the space library and aspect oriented programming stuff we talked
about a while ago.

http://tmb.voxel.net/papers/published/2001-breuel-tools.pdf

The paper itself is not particularly good, but a few nifty ideas.

Nick

-- 
Nick Collier 
Social Science Research Computing
University of Chicago 
http://repast.sourceforge.net

[Repast-developer] RePast/FAST Integration!

[North, M. <no...@an...>]

Loyal RePaster's:

I've completed the initial code to integrate the Flexible Agent Simulation
Toolkit (FAST) scheduler into RePast.  The two resulting versions of the
RePast code have been produced as follows:

Version 1:  This version replaces RePast's integer time steps with a double
precision numbers.  Furthermore, the new scheduler "fast forwards" to the
next scheduled event al a discrete event simulation instead of counting over
empty intervals.  A "stepSize" parameter has been added to MouseTrap as an
example.  This version has been committed to the RePast SourceForge
repository on the main branch.  I have done basic testing of this version,
but further testing is required before the updates can be generally used.
Nick and I (and other volunteers! Hint! Hint!) plan to further test Version
1 before looking at Version 2, to simplify the testing process.  

Version 2: This version builds on Version 1 and adds multi-threading to the
scheduler.  The new scheduler dispatches threads from a dynamic thread pool.
Multi-threading is currently implemented only for BasicActions executed
directly through ActionGroups, such as is done by Controller.  I will add
multi-threading of dynamically compiled BasicActions (i.e.. to
ByteCodeBuilder.generateBasicActionForList()) when the core multi-threading
code in Version 2 is fully tested (Leading to Version 3!).  A "stepSize"
parameter has been added to MouseTrap as an example.  This version will be
committed to the RePast SourceForge repository on the main branch when
Version 1 is fully tested.

As a note, I have rewritten the FAST routines to fully integrate into RePast
so no new classes where added.  Quite a few classes where changed however!

RePaster Michael

Michael J. North
Software Engineer
Argonne National Laboratory
Decision and Information Sciences Division
Complex Adaptive Systems Section

9700 S. Cass Avenue
Argonne, IL 60439

E-mail: no...@an...
Telephone: (630) 252-6234
Facsimile: (630) 252-6073

[Repast-developer] CVS branch done

[Nick C. <nic...@ve...>]

Hi,

I've branched CVS. The new branch is called rel-1-X. This means y'all
(except Mike) should do a "cvs update -r rel-1-X ." from the top of your
repast source tree. You can also move this directory to within some
other directory like repast-1X or whatever, in order to avoid confusion
with 2.0. 

Once you've done the update as described above, your working copy will
be tied to the rel-1-X branch. Please don't commit anything until you've
done this update!

Nick

-- 
Nick Collier 
Social Science Research Computing
University of Chicago 
http://repast.sourceforge.net

[Repast-developer] cvs branch

[Nick C. <nic...@ve...>]

Hi,

I'm going to branch the CVS tree tomorrow (thurs.) morning. The branch
will be repast-1_4. The idea here is that Mike North's changes to the
scheduler are now ready to go back into CVS for our consumption (thanks
Mike!). However, his changes are big enough that they won't be
introduced until 2.0, and we still have some work planned for 1.4.1 and
maybe beyond depending on when 2.0 is ready. The fork will allow us to
work on both simultaneously. At the moment, I think, Mike and I will be
the only ones working with 2.0. Tom and anybody else will be working
with 1.4. Of course, anyone can get 2.0 for their delectation but I know
Tom's current work is scheduled for release with 1.4.1 as is some code
I'm working on. 

So, once I've created the branch, y'all who are working on 1.4 will need
to update to this branch. To check out / update from a branch, you do:

cvs checkout -r repast-1-4 ...
cvs update -r repast-1-4 ...

More info on CVS branches can be found at:

http://www.loria.fr/~molli/cvs/doc/cvs_5.html#SEC49

Once your working copy is tied to the branch, any commit / updates can
be made as usual. Its probably a good idea to move your working copy to
a different source directory. So, if you have something like
~/src/repast/..., you could move the repast dir to ~/src/repast-1-4/,
and then do your cvs update -r repast-1-4 from there. 

As I said above, I'll be doing this tomorrow (thurs.) morning unless I
hear anything from y'all. Once I've done it, I'll send out an email and
y'all can do the update, and Mike can commit his new code to the main
branch.

Nick

-- 
Nick Collier 
Social Science Research Computing
University of Chicago 
http://repast.sourceforge.net

[Repast-developer] test

[Thomas H. <th...@sr...>]

developer list test from allman

[Repast-developer] Network surgery and some threading questions

[Nick C. <nic...@ve...>]

Hi,

Those of you that monitor the commits to the repast cvs archive will
have noticed a flurry of activity on my part. Here's the scoop.

I redid the accessor methods on NonGridDrawable to work with doubles
instead of ints. This required changes in lots of Node drawing classes
and interfaces that extend from this. This will also break any user code
that doesn't use repast provided node drawing classes. So, why then did
I do this.

1. These are NonGridDrawables so, semantically, their coordinates need
not be discrete integers. Its Network2DDisplay that needs to transform
their x and y coordinates into pixel coordinates and so the double to
int transform should be done there.

2. The GraphLayout classes work with doubles and a lot of the work they
do disappears when these doubles are used as integers.

3. I've implemented a new Zoomable interface for displays. You can now
drag a box around nodes and zoom in on them. In order for this to work
correctly we need the double coordinates from graphlayouts rather than
these coordinates rounded into integers.

I've updated the two network example models to reflect these changes.
One worked out of the box, and the other needed a only a few changes.

The other major change in the new code concerns threading. Some
background:

1. All drawing and other gui events in Java are handled via the event
thread. Drawing, that is, painting components, from threads other than
this one must use this thread to do the drawing.

2. RePast models make use of two threads relevant to this discussion.
The first is the gui thread mentioned above. Button clicks, etc. occur
through this thread, just like any other application. All model
activity, execution of actions etc. take place in another thread, the
RunThread. 

The recent changes effect how this RunThread works together with the
event thread in visualizing models. More specifically this refers to
calling updateDislay from within your model, that is, from with the
RunThread. The old code used SwingUtilities.invokeLater() to post the
paint event to the event thread. This worked fine with all code except
when using the KamadaKawai graph layout. Removing invokeLater and doing
a direct paint from the RunThread removed the problems with KamadaKawai.
This was particularly stupid on my part as it caused all kinds of
threading problems. So, this change only lasted a few days. The
currently commited code uses SwingUtilites.invokeAndWait(). This works
synchronously with the event thread as opposed to invokeLater which
works asynchronously. This fixes the problems with KamadaKawai and
allows the RunThread to work correctly with the event thread. However,
it is canonical to use invokeLater over invokeAndWait, so before I go
nailing anything to the church door I'd appreciate any comments.

The problem with KamadaKawai is that it contains lots of computationally
intensive loops and also calls updateDisplay (and thus invokeLater) from
within those loops. Consequently, lots of paint events get posted to the
event queue. So when the run thread goes to check the state of the event
queue it has to wait a long time for these paint events to be handled.
This in itself is not so bad, but the delay causes the toolbar, the
display and the parameter panel to get out synch with the runthread such
that it looks like the RunThread, and thus your simulation is paused or
stopped and ready to accept input (button clicks etc.) when it is not.
Its futzing with the display events in the event queue. 

Nick

-- 
Nick Collier 
Social Science Research Computing
University of Chicago 
http://repast.sourceforge.net

RE: [Repast-developer] Question on New Scheduler

[Laszlo G. <gu...@la...>]

Hi Michael,

First of all, thank you for the long and thoughtful answer.
I do share your view that reproducibility is an important
and complex issue.

In fact, in connection with my teaching activity one of
my long term projects is to put together a 'best practice'
manual on the statistical aspects of our computational
experiments. (I think this is one of our weak points as
a modelling community. Very few of the published models
account for their exact design of the replicative experiments.
In most cases [including my own work], it is simply stated
that the results are based on, say, 30 runs. But no word on
how the seeds were selected or what the confidence interval
of the result would be, etc.)

As for the multi-threaded scheduler, I was happy to
read about your thoughtful design. It made be much more
comfortable than I was after reading the original note about
it coming. Of course, it was all my fault to be too worried
about it, after all the quality work that has already went
into Repast.

Gulya

At 04:09 PM 1/7/02 -0600, you wrote:
>Gulya:
>
>Insuring that simulation results are reproducible is
>clearly an critical issue.  It should be noted that
>guaranteeing reproducible results is a concern that
>goes well beyond multi-threaded scheduling.  For
>example, the introduction of random numbers into
>simulations, as is commonly practiced with agent-based
>modeling, requires careful attention to insure
>reproducibility.  Furthermore, the implications of
>reproducibility require thoughtful consideration since
>most simulations that use random numbers are valid
>only when run in a stochastic mode.  Individual runs
>of such simulations may be useful for model debugging
>but should not be used to draw scientific conclusions.
>
>That being said, while multi-threaded scheduling in
>Java is non-deterministic even within a single virtual
>machine, multi-threaded programs still can be
>deterministic.  It all depends on the way that the
>programs are written.
>
>The new multi-threaded scheduler is being developed
>using the "Principle of Least Astonishment."  Thus,
>by default, the scheduler will operate in a
>deterministic, single-threaded mode.  This will
>prevent breakage of existing programs and new
>programmers alike.
>
>Multi-threaded scheduling can be activated on a
>case-by-case basis by specifying both a start time and
>an end time for tasks.  The start time is the
>simulation scheduling time you are already familiar
>with in RePast.  The end time defines when the
>results of a given task are available for other tasks.
>These other tasks may be run on separate, concurrent
>threads.  Details such as thread pooling and
>concurrency control will be automatically handled by
>the new scheduler.  Note that the end time is in the
>same units as the start time, which is to say units
>of simulation time, not wall clock or process time.
>
>Given a set of valid concurrent tasks, a new task can
>properly be started if the start time of the new task is
>less than or equal to the minimum end time of all of
>the currently running tasks.  This is true since the end
>time states when the results of a given task are available
>for other tasks to use.  The scheduler will use this
>rule to select tasks to be run concurrently.  It is up
>to model developers to properly specify end times if they
>wish tasks to be concurrent.  The details of managing and
>using this information will be embedded within the new
>scheduler.  The new RePast scheduler will thus make
>multi-threading available by simply adding optional
>simulation clock end times to the standard scheduler
>method calls.
>
>Clearly, proper use of multi-threading will require
>model developers to correctly set task end times.
>Choosing to use this new feature will thus create a
>new responsibility for developers.  However, which
>powerful programming feature can be used carelessly
>yet effectively?
>
>Michael
>
>-----Original Message-----
>From: Laszlo Gulyas [mailto:gu...@la...]
>Sent: Sunday, January 06, 2002 9:38 PM
>To: rep...@li...
>Subject: [Repast-developer] Question on New Scheduler
>
>
>Hi Everybody and Happy New Year to All,
>
>I seem to be lagging back on all the issues here, and I am
>sorry for that.
>
>My question here is about the new scheduling mechanism
>in the works that has been announced some weeks ago. I
>have to tell, it sounds terrific in general. What I am
>worried about, however, is replicability of the simulation results,
>when using multi-threaded scheduling. As far as I know,
>but I might be wrong of course, the exact scheduling of
>threads in Java is undeterministic (at least, accross
>JVMs). Am I right on this? If yes, can we still somehow
>guarantee that the simulation results will be reproducible?
>
>Well, that's it. Thanks for the answers in advance, and
>I am sorry if this what I wrote makes no sense.
>
>Gulya
>  --
>Laszlo Gulyas          (617) 384-9216
>Government Dept.       Weatherhead Center
>602C Coolidge Hall     for International Affairs
>1737 Cambridge str.    Cambridge, MA 02138
>
>_______________________________________________
>Repast-developer mailing list
>Rep...@li...
>https://lists.sourceforge.net/lists/listinfo/repast-developer
>
>_______________________________________________
>Repast-developer mailing list
>Rep...@li...
>https://lists.sourceforge.net/lists/listinfo/repast-developer

--
Laszlo Gulyas, MSc              Phone: (617) 
384-9216
Government Department   Weatherhead Center for International Affairs
Harvard University              602C Coolidge Hall
1737 Cambridge street           Cambridge, MA-02138

Re: [Repast-developer] aspectj and movement

[Nick C. <nic...@ve...>]

Hi all,

Re. our current direction on spaces, movement and aspects.

Well, I think the original idea and Tom should correct me here because
he's doing the actual prototyping while I do all the useless jabbering,
derives from the following chain of thought (mostly provoked by Gulya's
thoughts on spaces).

1. Many models have agents that move about some sort of space.

2. The agent moving code for these space is fairly similar.

3. Given 1 and 2, agent movement seems like a good candidate for
abstraction.

4. So, let's make a moveable agent base class that users can extend. 

5. However, this seems wrong-headed as agent movement is a "role" or
"aspect" rather than a core agent behavior. By core here I mean the
behavior that is the point of the agent model. Movement is a means to or
part of this behavior. Given Java's lack of multiple inheritance, a
moveable agent base class seems to make agent heirarchies more difficult
to code. For example, suppose I want to have agents that know how to
play a cooperation type game and move around looking for other agents to
play with. I can either use the moveable agent as my base class, or
repast GameAgent as my base class, not both. Of course, I can compose
one out of the other and forward the appropriate method calls, but this
is what I mean by more difficult to code. This is an ease of use issue
for the amateur programmer (i.e. the average repast soc. sci. user).

6. So, let's make a moveable agent interface. 

7. This makes no sense either as we have no client code that expects
agents to implement such an interface, and thus why make user's
implement such an interface. Moreover, the whole point here is that we
should provide the implementation for the users.

8. So, let's keep the interface, but have an aspect inject the
implementation. In this case, the interface is not for client code
interaction, but rather to mark the class, and let the user know what
methods are available. 

My current thoughts about all this. I'm not sure how much better this is
than the current situation. And as Tom has pointed out in his posts, the
non-standard space library seems to be getting in the way here. Perhaps
we should focus our efforts on reforming the space library for repast
2.0?

Nick

On Tue, 2002-01-08 at 18:33, Laszlo Gulyas wrote:
> Hi,
> 
> Well, I am not sure I completely understand what you are aimed at now,
> nor I think I made myself clear enough. (My own ideas aren't necessarily
> clear enough either.) This is because I actually have two 'scenarios' in
> my mind, which I consider as short and longer term goals. So, let me
> clarify these scenarios first, before getting back to your question.
> 
> [Personal struggle with ideas begins]
> 
> I)
> The short term goal would be to have the space lib. 'standardized'
> in a modular way, that I would baptise 'interchangeable spaces'.
> This would allow the modeler, given that she follows some reasonable
> coding guidelines (patterns), to use the same agent-model framework
> for different spaces. (I would not expect this to work for all the possible
> spaces, but for as much of them, as possible.)
> 
> Maybe, all of this becomes clearer if you have a look at the attached
> code, which is one of the 'test models' I am developing for the hexagonal
> space lib. (Note, that it is still work in progress.) Ultimately, it will 
> set up
> a space based on the parameters set by the user, will populate it by
> agents that do some basic behavior and which, if probed, paint their
> neighbors to a given color.
> 
> As you can see, it's fairly straightforward to do this right now, but some
> smoothening up of the general interfaces would make things much clearer
> and easier. [As an ultimate application of all this, think of an 'evolver-like'
> tool, in which you could select the space type from a pull-down menu...]
> 
> Naturally, this will work as long as we have a general interface for spaces.
> For 2D spaces, it is almost straightforward. It may also be possible for
> general 'grid-like' spaces, too (e.g., 3D, 1D -- BTW as a byproduct of one of
> my models, I have a Ring, ie. 1D Torus space as well). What I cannot see
> yet is how to incorporate networks, too. (Maybe, what you have in your
> aspect points to this direction...)
> 
> II)
> The longer term goal (well, maybe, dream) would be to free us from
> the _thinking_ in terms of data structures representing spatial structures
> (unless the space actually _has_ some behavior).
> 
> Say, my agents have 3 variables: a, b and c. To implement my model,
> I need to implement the behavior of them and display them somehow.
> Where we usually handle spaces is:
> 
>          1- to get references to other agents (resources) that are 'near',
>                in order to calculate the new values for a, b, and c;
>          2- to store (some mapping of) the new a, b, and c values in it, and
>          3- to create the display.
> 
> In an ideal world, these would be handled in the following way:
> 
>          1- I would call a method (of the model/environment/space after all?),
>              which takes an expression (say, describing agents whose value of
>              a is less than 2 units away from my a-value) and return references
>              to the objects described by the expression.
>          2- No need for it (theoretically, at least).
>          3- The display would basically be a mapping which goes over all
>              the agents and plots them according to their, say, a and c values.
>              (At least, it is this easy for grid-displays. I don't know 
> where this
>               would lead to in a more general case.)
> 
> Later, if I decide to change the underlying 'space representation', it could
> mean two things. I either want to display something else -- then I'd need to
> change the mapping under 3. Or I want to change the expression in 1.
> If I move from 2D to 3D, it simply means adding a new variable, plus changing
> the expression in 1. (And probably, changing the display mapping, but not
> necessarily.)
> 
> So, it must be clear from now, that this is really off the ground stuff. 
> But still,
> if it's possible, it might be useful, since it would require the modeler to 
> think
> in terms of model variables and expressions, instead of computational
> artefacts.
> 
> [Personal struggle ends]
> 
> Sorry, if I have repeated myself or if this ended up being boring.
> Where all this points back to your question is the following.
> 
> I don't know what of the goals above your approach is
> closer to, but my guess is that to that of under I). You can see,
> in that case, I am not afraid of referring to spaces at all.
> It would be nice, however, to have a look at the methods you
> have in the aspect. (I know it's well too premature.)
> 
> On the other hand, if it's about something like the wild dreams
> described under ii) then I am not sure I really understand how
> your aspect will work. (My original vague thought about using
> aspects was something along the lines of capturing all access
> to certain variables /say, x and y/ in the agents' code and
> using that to maintain a space object.)
> 
> I have the feeling that your work aims at something different
> from both of the scenarios I described above. Probably it's
> something much more realistic than those. So, if you don't
> mind, I'd look forward to a short explanation of your approach.
> 
> Well, in retrospect, I am not sure this was useful as an
> answer to the original question... :-)
> 
> Gulya
> 
> 
> At 10:09 AM 1/8/02 -0500, Nick Collier wrote:
> >Anybody have any ideas on how to hide the reference to the space? Tom
> >and I have been over this several times, but I'm keen to see what others
> >think?
> >
> >Nick
> >
> >On Tue, 2002-01-08 at 10:00, th...@sr... wrote:
> > > Yes, MoveableAgent is only a marker interface in a manner of speaking.
> > > That is, from the point of view of the user no code need be implemented.
> > > Now, as I have it written, the interface does have declarations.
> > > This could easily be changed.  However, I did this in order to document 
> > the
> > > operations that would be available to the agent.  If they weren't in the
> > > interface they would only be listed in the aspect and I fear that would be
> > > really confusing.  I guess that is my primary concern:  That the user
> > > understand what's available from MoveableAgent, but not have to worry 
> > about
> > > the implementation.
> > >
> > > As for the (general) architecture (And I emphasize, general), the
> > > interface Moveable agent contains methods called move and several 
> > overloaded
> > > getNeighbor functions.  All of these methods take a reference to the space
> > > object as a parameter.  This is kind of a pain because we don't really 
> > have a
> > > root space element, so I've separated it into Discrete2D and everyting 
> > else.
> > > Point being that the agent passes a reference to Object which then has 
> > to be
> > > casted in the aspect.  Oh well.  In order to use this, the user needs 
> > declare
> > > that the agent implements MoveableAgent.  Then, through the magic of 
> > aop, these
> > > methods are available for use.  This is a very loose description.
> > >
> > > Unfortunately, I think that it will be impossible for the agent to have no
> > > reference to it's space (Sorry Gulya :) ).
> > >
> > > -Tom
> > >
> > >
> > > On Tue, Jan 08, 2002 at 08:53:39AM -0500, Nick Collier wrote:
> > > > I'm a bit confused. Is MoveableAgent a marker interface? And if it
> > > > isn't, why not? That is, what sort of client code requires agents to be
> > > > MoveableAgents? I'm not asking this to be annoying, but rather to get a
> > > > sense of the big picture. (I know we've talked about this, but it would
> > > > be good to have something documented). Can you sketch the architecture
> > > > (perhaps too grand a notion here for a prototyping experiment), and walk
> > > > through the steps that a user has to do to get a MoveableAgent and what
> > > > they can do with it once they've got it.
> > > >
> > > > thanks,
> > > >
> > > > Nick
> > > >
> > > >
> > > >
> > > > On Mon, 2002-01-07 at 17:37, Laszlo Gulyas wrote:
> > > > > Hi,
> > > > >
> > > > > This is just off the top of my head, but I don't think having a
> > > > > flag- or identity interface should confuse the user. (As a
> > > > > matter of fact, they might get much more confused by
> > > > > aspects in general, but as I said before, I'd take the challenge.)
> > > > >
> > > > > In fact, repast already has identity interfaces (e.g. Torus
> > > > > in the space lib), but it might well be true that a user
> > > > > has never had to use them up to this point.
> > > > >
> > > > > Just my two cents.
> > > > >
> > > > > Gulya
> > > > >
> > > > > PS: I began to think that I should submit all my dreams
> > > > > to this list, given the response time by which, e.g. this
> > > > > independent-of-space dream of mine seems to be getting
> > > > > into shape... ;-)
> > > > >
> > > > > At 10:59 AM 1/7/02 -0600, Thomas Howe wrote:
> > > > > >Hi,
> > > > > >I am currently working on implement movement behaviour using aspect
> > > > > >oriented programming, so that the agent doesn't have to make calls
> > > > > >directly to the space.  We have discussed this a little on this 
> > list, and
> > > > > >I'm just checking the feasibility.
> > > > > >
> > > > > >Here's where I stand.  I am using aspectj as my aop language  I 
> > have an
> > > > > >"introduction aspect" as aspectj calls it, that adds a move method 
> > to the
> > > > > >class.  Basically, an introduction aspect adds new code to an 
> > existing
> > > > > >class.  This way the user never has to see the code, and we don't 
> > have
> > > > > >issues of multiple inheritence.  That's all fine and 
> > dandy.  Here's the
> > > > > >question.  In order to use this, the aspect has to be able to 
> > determine
> > > > > >which classes should have the added behaviour.  The best way that 
> > I can
> > > > > >think of to implement this is with interfaces.  For example, a 
> > class would
> > > > > >declare that it implements MoveableAgent and then the aspect adds 
> > the code
> > > > > >as appropriate.  I wonder, though, if this may be a problem.  From 
> > the
> > > > > >point of view of a user, when you declare that you implement an 
> > interface,
> > > > > >you always have to implement the methods yourself.  Will it be too
> > > > > >confusing to declare that you implement an interface without actually
> > > > > >writing any code?
> > > > > >
> > > > > >This was not the clearest note I've written, but I hope my point is
> > > > > >somewhat understandable.  Please let me know if it is not.
> > > > > >
> > > > > >Thanks,
> > > > > >Tom
> > > > > >
> > > > > >_______________________________________________
> > > > > >Repast-developer mailing list
> > > > > >Rep...@li...
> > > > > >https://lists.sourceforge.net/lists/listinfo/repast-developer
> > > > >
> > > > > --
> > > > > Laszlo Gulyas, MSc              Phone: (617)
> > > > > 384-9216
> > > > > Government Department   Weatherhead Center for International Affairs
> > > > > Harvard University              602C Coolidge Hall
> > > > > 1737 Cambridge street           Cambridge, MA-02138
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > Repast-developer mailing list
> > > > > Rep...@li...
> > > > > https://lists.sourceforge.net/lists/listinfo/repast-developer
> > > > --
> > > > Nick Collier
> > > > Social Science Research Computing
> > > > University of Chicago
> > > > http://repast.sourceforge.net
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > Repast-developer mailing list
> > > > Rep...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/repast-developer
> > >
> > > --
> > > Tom Howe
> > > Software Developer
> > > SRC
> > > University of Chicago
> > > 773-834-3382
> >--
> >Nick Collier
> >Social Science Research Computing
> >University of Chicago
> >http://repast.sourceforge.net
> >
> >
> >
> >_______________________________________________
> >Repast-developer mailing list
> >Rep...@li...
> >https://lists.sourceforge.net/lists/listinfo/repast-developer
> 
> --
> Laszlo Gulyas, MSc              Phone: (617) 
> 384-9216
> Government Department   Weatherhead Center for International Affairs
> Harvard University              602C Coolidge Hall
> 1737 Cambridge street           Cambridge, MA-02138
-- 
Nick Collier 
Social Science Research Computing
University of Chicago 
http://repast.sourceforge.net