Menu
▾
▴
repast-developer
You can subscribe to this list here.
| 2000 |
Jan
(3) |
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
(3) |
Sep
|
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
|
Feb
(1) |
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
(10) |
Sep
(14) |
Oct
(1) |
Nov
(21) |
Dec
(13) |
| 2002 |
Jan
(17) |
Feb
(2) |
Mar
(1) |
Apr
(2) |
May
(4) |
Jun
(2) |
Jul
(4) |
Aug
|
Sep
(7) |
Oct
(4) |
Nov
(12) |
Dec
(39) |
| 2003 |
Jan
(28) |
Feb
(18) |
Mar
(7) |
Apr
(5) |
May
(23) |
Jun
(29) |
Jul
(23) |
Aug
(18) |
Sep
(1) |
Oct
(5) |
Nov
(3) |
Dec
|
| 2004 |
Jan
(7) |
Feb
(2) |
Mar
(2) |
Apr
(2) |
May
(8) |
Jun
(2) |
Jul
(8) |
Aug
(2) |
Sep
(4) |
Oct
(3) |
Nov
|
Dec
|
| 2005 |
Jan
(2) |
Feb
(2) |
Mar
(13) |
Apr
(2) |
May
(2) |
Jun
(2) |
Jul
(32) |
Aug
(7) |
Sep
(11) |
Oct
(8) |
Nov
(16) |
Dec
(2) |
| 2006 |
Jan
(3) |
Feb
(1) |
Mar
(4) |
Apr
|
May
|
Jun
(1) |
Jul
(3) |
Aug
(3) |
Sep
|
Oct
(6) |
Nov
(1) |
Dec
(10) |
| 2007 |
Jan
(7) |
Feb
(6) |
Mar
(1) |
Apr
(5) |
May
(4) |
Jun
(6) |
Jul
(20) |
Aug
(21) |
Sep
(12) |
Oct
(4) |
Nov
(12) |
Dec
(17) |
| 2008 |
Jan
(18) |
Feb
(6) |
Mar
(9) |
Apr
(13) |
May
(14) |
Jun
(8) |
Jul
(23) |
Aug
(31) |
Sep
(26) |
Oct
(10) |
Nov
(3) |
Dec
(79) |
| 2009 |
Jan
(63) |
Feb
(13) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
(2) |
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2013 |
Jan
(1) |
Feb
|
Mar
|
Apr
(3) |
May
|
Jun
(1) |
Jul
|
Aug
(3) |
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2014 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
(2) |
Mar
(1) |
Apr
(2) |
May
|
Jun
(4) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(1) |
Nov
|
Dec
|
|
From: Stephen U. <sc...@np...> - 2008-12-10 15:55:29
|
Hi Michael, et al., Thanks for the new release!! Looks great! I have a small issue when I updated. It appears the terracotta demo can't find either RunGrid (in DoSomeActionAgent) or the RepastWork (in WorkItem) classes. Looking at the libraries, it appears there are no terracotta associated jars. All the other jars appear to have updated to 1.2. All demos appeared to work in 1.1. I used the Software Update in Eclipse (from the Repast Simphony IDE), on a Mac OS X. thanx steve Stephen C. Upton Research Associate SEED (Simulation Experiments & Efficient Designs) Center Operations Research Department Naval Postgraduate School Cell: 831-402-3888 NIPR: sc...@np... SEED Center web site: http://harvest.nps.edu On Dec 10, 2008, at 7:42 AM, North, Michael wrote: > On behalf of the Repast development team, I am pleased to announce the > release of Repast Simphony version 1.2. The new release includes the > following enhancements: > > 1. Simulation engine enhancements: > a. Dramatic performance enhancements for both GUI and non-GUI > models > b. SQL queries of contexts and networks available in > RepastEssentials > c. Schedule annotation processing updates > 2. Runtime interface enhancements: > a. New plugins: > i. A new *ORA (http://www.casos.cs.cmu.edu/projects/ora/) > network analysis plugin > ii. A new Pajek > (http://vlado.fmf.uni-lj.si/pub/networks/pajek/) network analysis > plugin > iii. A new live agent SQL query tool > (http://josql.sourceforge.net/) plugin > b. Substantially enhanced JUNG network statistics plugin > c. Charts: > i. Many additional chart customization options > ii. Chart performance enhancements > d. Displays: > i. Network source and target edge end styling > ii. Display background customization > iii. New 2D displays hover probe > e. A new control to adjust simulation execution speed > f. A new GUI option for custom XML freeze drying > 3. Visual agent editor enhancements: > a. A new code wizard > b. The ability to copy and paste flowchart blocks within and > between visual agents > c. Automatic HTML documentation generation from flowcharts > d. New point-and-click templates for: > i. Regression > ii. Neural networks > iii. Genetic algorithms > iv. Systems dynamics > v. SQL queries of contexts and networks > e. Templates for array properties > f. Flowchart image exporting to PNG, JPEG, BMP, and ICO formats > g. A snap blocks to grid option > h. Smooth group block moves > 4. A new point-and-click tree editor for batch run files > 5. A new point-and-click tree editor for legacy file integration > descriptions > > Current users can upgrade to version 1.2 using the Repast Eclipse > update > site. New users can download a full Eclipse installation or add > Repast to an > existing Eclipse installation. Please see > http://repast.sourceforge.net/download.html for details. > > Mike North > ---------------------------------------------------------------------- > -------- > SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, > Nevada. > The future of the web can't happen without you. Join us at MIX09 > to help > pave the way to the Next Web now. Learn more and register at > http://ad.doubleclick.net/clk;208669438;13503038;i?http:// > 2009.visitmix.com/ > _______________________________________________ > Repast-interest mailing list > Rep...@li... > https://lists.sourceforge.net/lists/listinfo/repast-interest |
|
From: North, M. <no...@an...> - 2008-12-10 12:42:52
|
On behalf of the Repast development team, I am pleased to announce the
release of Repast Simphony version 1.2. The new release includes the
following enhancements:
1. Simulation engine enhancements:
a. Dramatic performance enhancements for both GUI and non-GUI models
b. SQL queries of contexts and networks available in RepastEssentials
c. Schedule annotation processing updates
2. Runtime interface enhancements:
a. New plugins:
i. A new *ORA (http://www.casos.cs.cmu.edu/projects/ora/)
network analysis plugin
ii. A new Pajek
(http://vlado.fmf.uni-lj.si/pub/networks/pajek/) network analysis plugin
iii. A new live agent SQL query tool
(http://josql.sourceforge.net/) plugin
b. Substantially enhanced JUNG network statistics plugin
c. Charts:
i. Many additional chart customization options
ii. Chart performance enhancements
d. Displays:
i. Network source and target edge end styling
ii. Display background customization
iii. New 2D displays hover probe
e. A new control to adjust simulation execution speed
f. A new GUI option for custom XML freeze drying
3. Visual agent editor enhancements:
a. A new code wizard
b. The ability to copy and paste flowchart blocks within and between visual agents
c. Automatic HTML documentation generation from flowcharts
d. New point-and-click templates for:
i. Regression
ii. Neural networks
iii. Genetic algorithms
iv. Systems dynamics
v. SQL queries of contexts and networks
e. Templates for array properties
f. Flowchart image exporting to PNG, JPEG, BMP, and ICO formats
g. A snap blocks to grid option
h. Smooth group block moves
4. A new point-and-click tree editor for batch run files
5. A new point-and-click tree editor for legacy file integration
descriptions
Current users can upgrade to version 1.2 using the Repast Eclipse update
site. New users can download a full Eclipse installation or add Repast to an
existing Eclipse installation. Please see
http://repast.sourceforge.net/download.html for details.
Mike North
|
|
From: Nick C. <nic...@gm...> - 2008-12-01 14:18:16
|
I've had problems in the past, but not recently (especially as I was out all last week!). Nick On Nov 25, 2008, at 2:06 PM, Miles Parker wrote: > Is it just me (or my version of Eclipse) but has anyone else noticed > the sourceforge repository being flakey? I'm getting a lot of timeouts > which then seems to blow the local repository, so I have to try > again.. > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win > great prizes > Grand prize is a trip for two to an Open Source event anywhere in > the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Repast-developer mailing list > Rep...@li... > https://lists.sourceforge.net/lists/listinfo/repast-developer |
|
From: Miles P. <mil...@gm...> - 2008-11-25 19:06:39
|
Is it just me (or my version of Eclipse) but has anyone else noticed the sourceforge repository being flakey? I'm getting a lot of timeouts which then seems to blow the local repository, so I have to try again.. |
|
From: Jonathan O. <jo...@an...> - 2008-10-27 18:30:06
|
Hello Urs,
It looks like you are trying to use the New Project wizard in the
Development Environment ("Configuration B" in http://repast.sourceforge.net/docs/development.html)
. That is currently only supported in the User environment
(Configuration A).
If you describe your development needs, we might be able to see what
the best solution might be.
Jonathan
On Oct 24, 2008, at 1:32 AM, Urs Frei wrote:
> Hello Mike
> Thank you for your answer. :-)
> I have done the following:
> 1. download repastsvn over subversion
> 2. I import all the available plug-in in my Eclipse workspace.
> (In Eclipse "Import..." --> "General, Existing Project into
> Workspace" I go into the Folder RepastSVN\trunk and select every
> Project to import it)
> 3. Solving all compile error by edit the "Java Build Path" (java3D
> and so on)
> 4. Do "Project" --> "clean" and clean every Project
> 5. Create a launch configuration in Eclipse (config:
> Run a product:org.eclipse.sdk.ide,
> Tab Plug-ins: "all workspace and enabled target plug-ins)
>
> Now is the question what I have done wrong.
>
> Thank you
> bye
> Urs
>
>
>
> On Thu 23/10/08 10:44 PM , "North, Michael" no...@an... sent:
>
> Urs:
>
> How are you doing the installation? I noticed that “RepastSVN”
> appears in your local path. Are you tying to build from SVN?
>
> Mike
>
> From: Urs Frei [mailto:urs...@na...]
> Sent: Thursday, October 23, 2008 2:09 AM
> To: rep...@li...
> Subject: [Repast-developer] Launching in Eclipse --> File not found
>
> Hello
>
> After I reinstalled my Eclipse, I don't get now the wizard loading
> error. But I have the next problem.
>
> After I press finish on the create wizard I get a lot of errors:
>
> Error: Could not find "/setupfiles/ModelInitializer.agent"
> Error: Could not find "/setupfiles/ModelInitializer.txt"
> Error: Could not find "/setupfiles/docs/ReadMe.txt"
> Error: Could not find "/setupfiles/docs/index.html"
> Error: Could not find "/setupfiles/freezedried_data/ReadMe.txt"
> Error: Could not find "/setupfiles/icons/ReadMe.txt"
> Error: Could not find "/setupfiles/icons/model.png"
> Error: Could not find "/setupfiles/icons/model.bmp"
> ...
>
> Checked for C:\Programme\eclipse\workspace\RepastSVN\trunk\plugins
> \repast.simphony.bin_and_src_1.1.0\repast.simphony.bin_and_src.jar
> java.io.FileNotFoundException: C:\Programme\eclipse\workspace
> \RepastSVN\trunk\plugins
> \repast.simphony.bin_and_src_1.1.0\repast.simphony.bin_and_src.jar
> (Das System kann den angegebenen Pfad nicht finden)
> at java.util.zip.ZipFile.open(Native Method)
> at java.util.zip.ZipFile.(ZipFile.java:114)
> at java.util.jar.JarFile.(JarFile.java:133)
> at java.util.jar.JarFile.(JarFile.java:97)
> at
> repast
> .simphony
> .agents
> .designer
> .core.AgentBuilderPlugin.getJarPathList(AgentBuilderPlugin.java:1179)
> at
> repast
> .simphony
> .agents
> .designer
> .core
> .RepastProjectClasspathContainer
> .getClasspathEntries(RepastProjectClasspathContainer.java:43)
>
> Is there no possibility to start repast with the eclipse launch? It
> looks like to make first a kind of build to create the
> repast.simphony.bin_and_src.jar.
>
> Thanks for help
>
> Urs
>
>
>
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win
> great prizes
> Grand prize is a trip for two to an Open Source event anywhere in
> the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/_______________________________________________
> Repast-developer mailing list
> Rep...@li...
> https://lists.sourceforge.net/lists/listinfo/repast-developer
|
|
From: SourceForge.net <no...@so...> - 2008-10-25 18:04:10
|
Bugs item #2194882, was opened at 2008-10-25 18:04 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101703&aid=2194882&group_id=1703 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Repast Simphony Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Batch Run Launcher: parameter file without quotation mark Initial Comment: When a project is created the batch launcher has a problem with the arguments. The -params option doesn't have quotation marks, so if the path for batch_params.xml has any space in it, the program will not found it and will stop without any message. It would be good to give an error message if the batch_params.xml file is not found. jgs...@ia... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101703&aid=2194882&group_id=1703 |
|
From: SourceForge.net <no...@so...> - 2008-10-24 16:55:45
|
Bugs item #2192308, was opened at 2008-10-24 12:55 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101703&aid=2192308&group_id=1703 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Repast Simphony Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: S. Vasa (s_vasa) Assigned to: Nobody/Anonymous (nobody) Summary: Index out of range ValuLayerDiffuser.diffuse() Initial Comment: In the method diffuse() of file ValueLayerDiffuser.java in package repast.simphony.valuLayer in the repast.simphony.core plugin; at lines 333-335 the array limits are set for the wrong indices: for (int x = 0; x < newVals[0].length; x++) { for (int y = 0; y < newVals[0][0].length; y++) { for (int z = 0; z < newVals.length; z++) { They should be changed to: for (int x = 0; x < newVals.length; x++) { for (int y = 0; y < newVals[0].length; y++) { for (int z = 0; z < newVals[0][0].length; z++) { To test: 1. create a 3 dimensional ValueLayerDiffuser with differing dimension sizes in the ValueLayer, i.e., x=40, y=30, z=20 2. run model 3. error ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101703&aid=2192308&group_id=1703 |
|
From: Urs F. <urs...@na...> - 2008-10-24 06:33:03
|
Hello Mike
Thank you for your answer. :-)
I have done the following:
1. download repastsvn over subversion
2. I import all the available plug-in in my Eclipse workspace.
(In Eclipse "Import..." --> "General, Existing Project into
Workspace" I go into the Folder RepastSVNtrunk and select every
Project to import it)
3. Solving all compile error by edit the "Java Build Path" (java3D
and so on)
4. Do "Project" --> "clean" and clean every Project
5. Create a launch configuration in Eclipse (config:
Run a product:org.eclipse.sdk.ide,
Tab Plug-ins: "all workspace and enabled target plug-ins)
Now is the question what I have done wrong.
Thank you
bye
Urs
On Thu 23/10/08 10:44 PM , "North, Michael" no...@an... sent:
v:* {behavior:url(#default#VML);} o:*
{behavior:url(#default#VML);} w:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
Urs:
How are you doing the installation? I noticed that “RepastSVN”
appears in your local path. Are you tying to build from SVN?
Mike
-------------------------
FROM: Urs Frei [mailto:urs...@na...]
SENT: Thursday, October 23, 2008 2:09 AM
TO: rep...@li...
SUBJECT: [Repast-developer] Launching in Eclipse --> File not found
Hello
After I reinstalled my Eclipse, I don't get now the wizard loading
error. But I have the next problem.
After I press finish on the create wizard I get a lot of errors:
Error: Could not find "/setupfiles/ModelInitializer.agent"
Error: Could not find "/setupfiles/ModelInitializer.txt"
Error: Could not find "/setupfiles/docs/ReadMe.txt"
Error: Could not find "/setupfiles/docs/index.html"
Error: Could not find "/setupfiles/freezedried_data/ReadMe.txt"
Error: Could not find "/setupfiles/icons/ReadMe.txt"
Error: Could not find "/setupfiles/icons/model.png"
Error: Could not find "/setupfiles/icons/model.bmp"
...
Checked for
C:ProgrammeeclipseworkspaceRepastSVNtrunkpluginsrepast.simphony.bin_and_src_1.1.0repast.simphony.bin_and_src.jar
java.io.FileNotFoundException:
C:ProgrammeeclipseworkspaceRepastSVNtrunkpluginsrepast.simphony.bin_and_src_1.1.0repast.simphony.bin_and_src.jar
(Das System kann den angegebenen Pfad nicht finden)
at java.util.zip.ZipFile.open(Native Method)
at java.util.zip.ZipFile.(ZipFile.java:114)
at java.util.jar.JarFile.(JarFile.java:133)
at java.util.jar.JarFile.(JarFile.java:97)
at
repast.simphony.agents.designer.core.AgentBuilderPlugin.getJarPathList(AgentBuilderPlugin.java:1179)
at
repast.simphony.agents.designer.core.RepastProjectClasspathContainer.getClasspathEntries(RepastProjectClasspathContainer.java:43)
Is there no possibility to start repast with the eclipse launch? It
looks like to make first a kind of build to create the
repast.simphony.bin_and_src.jar.
Thanks for help
Urs
|
|
From: North, M. <no...@an...> - 2008-10-23 20:44:50
|
Urs: How are you doing the installation? I noticed that "RepastSVN" appears in your local path. Are you tying to build from SVN? Mike ________________________________ From: Urs Frei [mailto:urs...@na...] Sent: Thursday, October 23, 2008 2:09 AM To: rep...@li... Subject: [Repast-developer] Launching in Eclipse --> File not found Hello After I reinstalled my Eclipse, I don't get now the wizard loading error. But I have the next problem. After I press finish on the create wizard I get a lot of errors: Error: Could not find "/setupfiles/ModelInitializer.agent" Error: Could not find "/setupfiles/ModelInitializer.txt" Error: Could not find "/setupfiles/docs/ReadMe.txt" Error: Could not find "/setupfiles/docs/index.html" Error: Could not find "/setupfiles/freezedried_data/ReadMe.txt" Error: Could not find "/setupfiles/icons/ReadMe.txt" Error: Could not find "/setupfiles/icons/model.png" Error: Could not find "/setupfiles/icons/model.bmp" ... Checked for C:\Programme\eclipse\workspace\RepastSVN\trunk\plugins\repast.simphony.b in_and_src_1.1.0\repast.simphony.bin_and_src.jar java.io.FileNotFoundException: C:\Programme\eclipse\workspace\RepastSVN\trunk\plugins\repast.simphony.b in_and_src_1.1.0\repast.simphony.bin_and_src.jar (Das System kann den angegebenen Pfad nicht finden) at java.util.zip.ZipFile.open(Native Method) at java.util.zip.ZipFile.<init>(ZipFile.java:114) at java.util.jar.JarFile.<init>(JarFile.java:133) at java.util.jar.JarFile.<init>(JarFile.java:97) at repast.simphony.agents.designer.core.AgentBuilderPlugin.getJarPathList(A gentBuilderPlugin.java:1179) at repast.simphony.agents.designer.core.RepastProjectClasspathContainer.get ClasspathEntries(RepastProjectClasspathContainer.java:43) Is there no possibility to start repast with the eclipse launch? It looks like to make first a kind of build to create the repast.simphony.bin_and_src.jar. Thanks for help Urs |
|
From: Urs F. <urs...@na...> - 2008-10-23 07:09:31
|
BODY { font-family:Arial, Helvetica, sans-serif;font-size:12px; }
Hello
After I reinstalled my Eclipse, I don't get now the wizard loading
error. But I have the next problem.
After I press finish on the create wizard I get a lot of errors:
Error: Could not find "/setupfiles/ModelInitializer.agent"
Error: Could not find "/setupfiles/ModelInitializer.txt"
Error: Could not find "/setupfiles/docs/ReadMe.txt"
Error: Could not find "/setupfiles/docs/index.html"
Error: Could not find "/setupfiles/freezedried_data/ReadMe.txt"
Error: Could not find "/setupfiles/icons/ReadMe.txt"
Error: Could not find "/setupfiles/icons/model.png"
Error: Could not find "/setupfiles/icons/model.bmp"
...
Checked for
C:ProgrammeeclipseworkspaceRepastSVNtrunkpluginsrepast.simphony.bin_and_src_1.1.0repast.simphony.bin_and_src.jar
java.io.FileNotFoundException:
C:ProgrammeeclipseworkspaceRepastSVNtrunkpluginsrepast.simphony.bin_and_src_1.1.0repast.simphony.bin_and_src.jar
(Das System kann den angegebenen Pfad nicht finden)
at java.util.zip.ZipFile.open(Native Method)
at java.util.zip.ZipFile.(ZipFile.java:114)
at java.util.jar.JarFile.(JarFile.java:133)
at java.util.jar.JarFile.(JarFile.java:97)
at
repast.simphony.agents.designer.core.AgentBuilderPlugin.getJarPathList(AgentBuilderPlugin.java:1179)
at
repast.simphony.agents.designer.core.RepastProjectClasspathContainer.getClasspathEntries(RepastProjectClasspathContainer.java:43)
Is there no possibility to start repast with the eclipse launch? It
looks like to make first a kind of build to create the
repast.simphony.bin_and_src.jar.
Thanks for help
Urs
|
|
From: Urs F. <urs...@na...> - 2008-10-22 18:09:21
|
Hello I am absolutely frustrated. I am new in repast. So I tried to do the tutorial but this doesn't work (see mailing list). To find the problem I downloaded the source (ref 403) from repast and hope the newer version solves my problem. But now I can not make a repast project. The error I get is: Problem Opening Wizard. The selected wizard could not be started. Details --> The selected wizard could not be started. Plug-in "repast.simphony.score.agents" was unable to instantiate class "repast.simphony.agents.designer.ui.wizards.NewProjectCreationWizard". java.lang.ExceptionInInitializerError If I debug the problem I see the exception will be thrown in the class ScorePackageImple.java on line 963. The variable packageFilename has the value score.ecore. My environment: Eclipse 3.4.1 Java 1.6.0_5 Has someone any idea? Thank you for your help Urs |
|
From: SourceForge.net <no...@so...> - 2008-10-07 20:27:40
|
Bugs item #2007032, was opened at 2008-06-30 18:56 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101703&aid=2007032&group_id=1703 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Repast Simphony Group: None Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Luis Diaz de Cerio (ldiazldiaz) Assigned to: Michael J. North (michaelnorth) Summary: Repast wizard problems Initial Comment: I have eclipse SDK 3.3.2 on kubuntu 8.04. In order to install the repast plugins I have followed the installation steps on: http://repast.sourceforge.net/plugin-installation.html When I try to select "repast simphony proyect" wizard I got this error: "The selected wizard could not be started. Plugin "repast.simphony.agents" was unable to instantiate class "repast.simphony.agents.designer.ui.wizards.NewProjectCreationWizard" Any help would be very appreciated. Thank you ldi...@gm... ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2008-10-07 20:27 Message: You have noted that an "java.lang.ExceptionInInitializerError" error message is generated. Can you post the full error message including call stack so I can check source of the problem? ---------------------------------------------------------------------- Comment By: Robsteranium (robsteranium) Date: 2008-10-02 21:58 Message: Please might we re-open this issue? I'm having the same problem on Eclipse 3.2, Xubuntu 8.04. Eclipse works fine with other plug-ins. I just got rid of java-cgj and have forced eclipse to use java-6-sun-1.6.0.07. Now the error is rather less descriptive: java.lang.ExceptionInInitializerError. I've had Repast Simphony working on the same version of eclipse on OS X so I'm not sure what's wrong. When I have the time I'm going to try downloading from sourceforge rather than via the eclipse remote update and then perhaps trying Eclipse 3.4 as suggested in the install instructions. I'd be grateful for any advice in the meantime! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101703&aid=2007032&group_id=1703 |
|
From: SourceForge.net <no...@so...> - 2008-10-02 21:58:40
|
Bugs item #2007032, was opened at 2008-06-30 18:56 Message generated for change (Comment added) made by robsteranium You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101703&aid=2007032&group_id=1703 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Repast Simphony Group: None Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Luis Diaz de Cerio (ldiazldiaz) Assigned to: Michael J. North (michaelnorth) Summary: Repast wizard problems Initial Comment: I have eclipse SDK 3.3.2 on kubuntu 8.04. In order to install the repast plugins I have followed the installation steps on: http://repast.sourceforge.net/plugin-installation.html When I try to select "repast simphony proyect" wizard I got this error: "The selected wizard could not be started. Plugin "repast.simphony.agents" was unable to instantiate class "repast.simphony.agents.designer.ui.wizards.NewProjectCreationWizard" Any help would be very appreciated. Thank you ldi...@gm... ---------------------------------------------------------------------- Comment By: Robsteranium (robsteranium) Date: 2008-10-02 21:58 Message: Please might we re-open this issue? I'm having the same problem on Eclipse 3.2, Xubuntu 8.04. Eclipse works fine with other plug-ins. I just got rid of java-cgj and have forced eclipse to use java-6-sun-1.6.0.07. Now the error is rather less descriptive: java.lang.ExceptionInInitializerError. I've had Repast Simphony working on the same version of eclipse on OS X so I'm not sure what's wrong. When I have the time I'm going to try downloading from sourceforge rather than via the eclipse remote update and then perhaps trying Eclipse 3.4 as suggested in the install instructions. I'd be grateful for any advice in the meantime! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101703&aid=2007032&group_id=1703 |
|
From: Nick C. <nic...@gm...> - 2008-09-22 20:33:18
|
Stefan, The answer may unfortunately be "no", but can you say a bit more. Under batch mode, the plugin mechanism is not in play and so plain eclipse importing should work. Also, if the jar doesn't depend on code in repast then it should be possible to have it in the root classpath which is equivalent to plain eclipse importing. Nick On Sep 22, 2008, at 9:38 AM, Stefan König wrote: > > Dear all, > > we are currently developing a Repast S-based grid and cloud computing > simulation toolkit. The core project is realized as a very generic and > comprehensive toolkit. We envision this simulator to be re-used in > more > application specific simulation frameworks (also Repast-based, of > course). > > For this purpose the core toolkit will be published as open source > soon. In > order to use the developed API in more specific simulation toolkits, > it > would be best if potential users can include this toolkit as a jar- > file into > their specific projects. Since plain Eclipse-importing is not > working during > simulation runtime, we would be interested in a simpler way to do so > apart > from the one mentioned below. > > This is of special importance to us since the current approach is > not very > handy for open source users. > > Best regards and thanks in advance, > > Stefan. > > > > tbergenhill wrote: >> >> Hello: >> >> I'm working on incorporating ProActive v3.2.1 into a Repast-S alpha2 >> model (on Windows XP), and the model is having problems locating >> classes found in the supporting JARs for ProActive. I replaced the >> out-of-date ProActive.jar in the repast.simphony.core/lib directory >> with the v3.2.1 JAR file, and I placed all the supporting JAR files >> in >> this directory as well. But I still get a NoClassDefFoundError on >> org/objectweb/fractal/api/factory/InstantiationException (which is >> located in the fractal.jar that I placed in the lib directory). >> >> It seems that ProActive.jar is part of the saf.core.runtime.Boot >> integrity check, so the ProActive classes are discovered. But how >> do I >> get the other classes in the supporting JAR files to be discovered? >> >> -- >> Tobin Bergen-Hill >> Lead Simulation Modeling Engineer, E526 >> <http://info.mitre.org/phonebookv2/organization.do?orgCode=E526> >> tbe...@mi... >> 703-983-3759 >> >> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by DB2 Express >> Download DB2 Express C - the FREE version of DB2 express and take >> control of your XML. No limits. Just data. Click to get it now. >> http://sourceforge.net/powerbar/db2/ >> _______________________________________________ >> Repast-developer mailing list >> Rep...@li... >> https://lists.sourceforge.net/lists/listinfo/repast-developer >> >> > > -- > View this message in context: http://www.nabble.com/Supporting-ProActive-JARs-Not-Found-tp11668202p19608142.html > Sent from the repast-developer mailing list archive at Nabble.com. > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win > great prizes > Grand prize is a trip for two to an Open Source event anywhere in > the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Repast-developer mailing list > Rep...@li... > https://lists.sourceforge.net/lists/listinfo/repast-developer |
|
From: SourceForge.net <no...@so...> - 2008-09-22 14:01:06
|
Bugs item #2122889, was opened at 2008-09-22 16:00 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101703&aid=2122889&group_id=1703 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Repast Simphony Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stefan (evets812000) Assigned to: Nobody/Anonymous (nobody) Summary: ClassCast problem in ShortestPath Initial Comment: This bug regards the repast.simphony.space.graph.ShortestPath class: Although only demanding an object of the generic Interface "Network<T>" at the constructor the "getPath" Method casts this object to a specific Network: a ContextJungNetwork. An UndirectedJungNetwork for example that was passed to the constructor will result in a ClassCastException when executing this method, although the constructor works fine. Best regards, Stefan. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101703&aid=2122889&group_id=1703 |
|
From: Stefan K. <Ste...@un...> - 2008-09-22 13:39:06
|
Dear all, we are currently developing a Repast S-based grid and cloud computing simulation toolkit. The core project is realized as a very generic and comprehensive toolkit. We envision this simulator to be re-used in more application specific simulation frameworks (also Repast-based, of course). For this purpose the core toolkit will be published as open source soon. In order to use the developed API in more specific simulation toolkits, it would be best if potential users can include this toolkit as a jar-file into their specific projects. Since plain Eclipse-importing is not working during simulation runtime, we would be interested in a simpler way to do so apart from the one mentioned below. This is of special importance to us since the current approach is not very handy for open source users. Best regards and thanks in advance, Stefan. tbergenhill wrote: > > Hello: > > I'm working on incorporating ProActive v3.2.1 into a Repast-S alpha2 > model (on Windows XP), and the model is having problems locating > classes found in the supporting JARs for ProActive. I replaced the > out-of-date ProActive.jar in the repast.simphony.core/lib directory > with the v3.2.1 JAR file, and I placed all the supporting JAR files in > this directory as well. But I still get a NoClassDefFoundError on > org/objectweb/fractal/api/factory/InstantiationException (which is > located in the fractal.jar that I placed in the lib directory). > > It seems that ProActive.jar is part of the saf.core.runtime.Boot > integrity check, so the ProActive classes are discovered. But how do I > get the other classes in the supporting JAR files to be discovered? > > -- > Tobin Bergen-Hill > Lead Simulation Modeling Engineer, E526 > <http://info.mitre.org/phonebookv2/organization.do?orgCode=E526> > tbe...@mi... > 703-983-3759 > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Repast-developer mailing list > Rep...@li... > https://lists.sourceforge.net/lists/listinfo/repast-developer > > -- View this message in context: http://www.nabble.com/Supporting-ProActive-JARs-Not-Found-tp11668202p19608142.html Sent from the repast-developer mailing list archive at Nabble.com. |
|
From: devlin a. <ha...@rc...> - 2008-09-18 12:54:34
|
approved prescriptions safe and effective see us here |
|
From: Meagan D. <Me...@an...> - 2008-09-17 09:15:45
|
I'm very hot girl, who is looking to meet you, or chat in skype with webcam! my e-mail for you hot reply: HV...@am... I want your answer! You bad lady ing his way on the American scene, trying to make his mark, SorosBut while classical economics taught the concept of equilibrium, |
|
From: Deland <Del...@So...> - 2008-09-17 01:39:29
|
make your cock full size for full control http://www.halokero.com/ <http://www.halokero.com/> |
|
From: Leszek <she...@CY...> - 2008-09-16 09:06:20
|
Enhance your pinis and make her suck your super sized rod now. You will feel all the pleasures. Find out how http://www.bevybunk.com/ <http://www.bevybunk.com/> |
|
From: Robert D L. <rob...@ya...> - 2008-09-16 07:25:09
|
I came across a good paper which benchmarks the new NVidia GPUs [1] which I thought would be of interest to people reading this thread. Doing matrix-matrix multiplication, you needed to be working with a matrix size of ~1000 before you begin to see an advantage. However, there was also a benchmark with Monte Carlo Black-Scholes (Black-Sholes is effectively a 1D reverse time diffusion equation) which may have been promising. The algorithm for this calculates partial sum and square of the options price, each generated by a single thread and a single run of MCBS consists of a single "experiment". What was promising about this was that the S870 GPu was able to calculate 950 million "experiments/second" vs 300M/s for a 2 socket Quad core 3.0Ghz Xeon (8 cores), and ~40M/second for a single core Xeon. They used 4096 threads to benchmark this, but it wasn't clear if a single experiment required all 4096 threads, or if this was broken up to run several experiments in parallel. Because coallation would still be a bottle neck, future agent based systems which require high computational loads it might want to look to advances with physics simulators, which must also deal with the problems of "collision". I have worked with the Vortex physics engine, and if I remember correctly, they use a divide and conquer algorithm to divide up the space into regions to handle collision detection, flagging objects which are in range for a "potential collision" and handling objects which may collide with the objects in other domains when they are near the boarders. [1] http://www.hp.com/techservers/hpccn/hpccollaboration/ADCatalyst/downloads/ac celerating_HPC_Using_GPU's.pdf -----Original Message----- From: Miles Parker [mailto:mi...@ME...] Sent: Monday, September 15, 2008 2:24 PM To: Michael North; Robert D Leclerc; Collier, Hugh N. Cc: rep...@li... Subject: Re: [Repast-developer] [Repast-interest] Multithreading andScheduledMethod Yes, an important point -- and one supported by the fact that we all got nearly the same results in independent experiments. Fundamentally I suppose its the communication v. computation trade-off. and when you increase the necessity for communication, you're going push the sweet spot toward computation. On the other hand, I'm not sure that there is something fundamentally at odds with light-weight agents and parallel execution -- though I would agree that that is true for the way that we are likely doing things now. As long as agents -- or the great majority of them -- are not in communication with other agents -- or only a small subset of them -- and one doesn't are about determined agent execution, then given the inherent locality of ABM models I think you should be able to approach 1/P time in the optimal case. But perhaps the take-home is that that is very difficult to achieve within the context of a general purpose API based scheduler that is designed to support nicely ordered predictable robust execution. On Sep 15, 2008, at 10:46 AM, North, Michael wrote: > > I'd like to add that the underlying issues go well beyond Repast, > Ascape, or even Java. Fundamentally, it can be challenging to create > efficient parallel programs and that even with the best tools only > certain limited classes of problems are currently amenable to such > implementations. A good resource on the design issues is Ian Foster's > "Designing and Building Parallel Programs" web site: > > http://www-unix.mcs.anl.gov/dbpp/ > > If an algorithm has poor scalability as defined by Ian's "A > Quantitative > Basis for Design" chapter (http://tinyurl.com/54r3uc) then no toolkit > whether it be in Java 6, Java 7, C/C++. High Performance Fortran or > whatever can get it to run efficiently in parallel. Agent-based models > that have a large number of agents doing a small amount of work at > every > time step are likely to fall into the category of poor scalability. > Other classes of agent models which have agents doing large amounts of > work per time step have at least the potential for, although not the > guarantee of, better scalability. > > Mike > > -----Original Message----- > From: rep...@li... > [mailto:rep...@li...] On Behalf Of > Robert D Leclerc > Sent: Monday, September 15, 2008 9:06 AM > To: Collier, Hugh N. > Cc: rep...@li...; 'Miles Parker' > Subject: Re: [Repast-developer] [Repast-interest] Multithreading > andScheduledMethod > > (References are at end) > > Supposedly there are significant concurrency additions planned for > Java > 7 > [1-3], so it might be advisable to wait until then. In particular > there > are > plans for adding the "Fork-Join" (FJ) framework [2-4], which uses some > special high performance threads [5]. Doug Le mentions that > "java.lang.Thread (as well as POSIX pthreads, upon which java threads > are > based) are sub-optimal for fork-join programs" because these are too > heavy > for FJ and because FJ tasks never need to block except to wait out > sub-tasks" and because they are too heavy. > > For anyone multithreading your applications, you should read the paper > fork-join framework [4]. However, as I discussed earlier, a quick and > dirty > way to increase performance on a multicore system is to schedule > duplicate > methods in the Context to run at the same time and the same duration, > and > maintain your agents in a list so that at some tick t, both methods > run > concurrently processing separate halves of the list. For example: > > Class MySpace implements Context{ > > //Space Details > > @ScheduleMethod(start=0.1, interval=1, duration=0.1) > public void processFirstHalf(){ > for(i = 0; i < firstHalf; i++){ > agentList.get(i).step(); > } > } > > @ScheduleMethod(start=0.1, interval=1, duration=0.1) > public void processSecondHalf (){ > for(i = firstHalf; i < agentList.size(); i++){ > agentList.get(i).step(); > } > } > } > > Here processFirstHalf() and processSecondHalf() will run concurrently > and > process agents in parallel. > > However, you should only be doing this steps which don't affect other > agents > and each agent could submit themselves to an arbitrator if they > require > some > interaction with the environment or other agents. Also, you need to > update > the list as you add/remove agents outside of these methods. Using 2 > methods > might get you about a 50% performance improvement for two threads on a > n>1 > core system. Moreover, it didn't appear that additional > parallelization > using n>2 methods helped in a simulation with 900 agents. However, > some > of > this might be due to thread safe collections used by RePast. > > Best, > RDL > > > Some interesting articles I cam across: > [1] http://www.infoq.com/news/2007/07/concurrency-java-se-7 > > [2] > http://www.ibm.com/developerworks/java/library/j-jtp11137.html?S_TACT=10 > 5AGX > 02&S_CMP=ART > > [3] http://www.ibm.com/developerworks/java/library/j-jtp03048.html > > [4] http://gee.cs.oswego.edu/dl/papers/fj.pdf > > [5] > http://g.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/FJTask.h > tml > > > [2] > > > > -----Original Message----- > From: Nick Collier [mailto:nic...@gm...] > Sent: Monday, September 15, 2008 8:53 AM > To: Robert D Leclerc > Cc: 'Miles Parker'; rep...@li... > Subject: Re: [Repast-developer] [Repast-interest] Multithreading and > ScheduledMethod > > Thanks for posting this info. Its been my own experience as well that > the threaded tasks need to be few and quite heavy to see any > "noticeable" performance improvement. Where I saw the best improvement > was with an ant algorithm implementation using many thousands of ants > where batches of ants operated in parallel. This also followed the > same type of read / update phase that you and Miles mentioned earlier. > > I had the opposite experience trying to parallelize some shapefile > processing code. The complexity of the code became an issue and the > performance improvement was in the end too small to justify it. > > That said, there's probably room for improvement in Repast w/r to > Thread creation, pooling and so forth. Parts of the implementation > were written before the JDK made such things much easier. > > Nick > > On Sep 13, 2008, at 2:49 PM, Robert D Leclerc wrote: > >> I did some testing with RePasts scheduler as a way to test the >> possibility >> of using multiple cores (I should have thought about this earlier). >> >> In the context I cached all the agents to array. In the context I >> then >> created 4 methods that were scheduled at the same time and had the >> same >> duration. Each of the scheduled methods iterated through a different >> section >> of the array calling a method on the agent. In this way I could test >> how >> long it would take to run on my quad core processor. If I used only >> one >> method to iterate through the whole array, it took 16 seconds. If I >> used 2 >> methods, each iterating through separate halves, it took 12 seconds. >> However, as soon as I tried it with 3 and 4 methods running at the >> same >> time, it began to take longer than when I used 2 methods running at >> the same >> time. >> >> This again suggests that it may be difficult to get RePast (or any >> other >> Java based ABMS for that matter) to take advantage of multicore >> processors >> unless it meets some conditions. >> >> Best, >> RDL >> >> >> >> >> -----Original Message----- >> From: Miles Parker [mailto:mi...@ME...] >> Sent: Friday, September 12, 2008 4:22 PM >> To: Robert D Leclerc >> Cc: Nick Collier; rep...@li... >> Subject: Re: [Repast-interest] Multithreading and ScheduledMethod >> >> >> [hope you don't mind that I cc'd the develop list] >> >> Cool. [I wrote the Ascape code before there was all of that nice >> built- >> in java concurrency stuff. :)] >> >> That's an important point about using the Context as the point of >> action. This is a very logical place for control, but also for >> inference! In general, this is true for any collection of agents, >> e.g. >> Scapes, Projections, Swarms..* This is the way that the >> parallelization** went down in the Ascape architecture but it is a >> consequence of the Scape structure so it isn't really obvious. You >> have Scape grained control over the style of execution. The Strategy >> factory will make inferences about the scape's rules sets and >> determine wether it it reasonable to try to run some rules in >> parallel. >> >> For example, if you have a Scape Array with a Diffusion rule the >> framework will know that it is safe to run in parallel. This is >> because Diffusion returns false for "isRandomExecution" which means >> that it does not have an effect on its neighbors that needs to happen >> in any particular order. And since Array is immutable we know that we >> don't need to worry about the population size changing. >> >> For the Scape Population, those qualities would not hold true because >> spatial individual effects mean that order does matter. But one could >> imagine using richer semantics allowing the kinds of thing you're >> suggesting below. >> >> So while it makes sense to have intelligence at the Context/ >> collection/ >> Scape level, schedule annotations on context alone would maybe not be >> granular/rich enough at this point. >> >> *btw, I'm moving back to the view that there is a role for a >> scaffolding Scape structure in the ABM meta-model collaborating w/ >> Context and Projections. I'm going to play around a bit with this as >> there seems to be some kind of generic unified model lurking in there >> somewhere. Thoughts anyone? >> >> **LOL, I horribly misspelled "Parallelization" and when I clicked on >> the Apple Mail Spell Check the only thing it could come up with was >> "Paralyzation"! >> >> >> Miles T. Parker >> Principal >> Metascape, LLC >> "Extraordinary Tools for Extraordinary Science" >> mi...@me... >> http://metascapeabm.com >> >> On Sep 12, 2008, at 11:15 AM, Robert D Leclerc wrote: >> >>> Miles, >>> >>> If you are interested, I attached a WorkerService class which can be >>> easily >>> dropped into RePast. This will allow you to create n number of >>> worker >>> threads which execute a method on a set of objects, and blocking >>> until all >>> the objects have evoked and returned from their method calls. You >>> can >>> specify which method to execute in the constructor by either (a) >>> specifying >>> the class and method name for the object type, or (b) implementing a >>> ProxiedMethod interface which makes the specific method call. >>> >>> ParallelWorkServiceDemo (attached) has a very short example and you >>> can >>> basically use this with 2 lines of code, and not worry about it as >>> long as >>> you are not doing anything else at this time. >>> >>> Nick emailed me also, so I sent him this code as well in case he >>> finds some >>> use for it in future versions of the scheduler. It would seem to me >>> that >>> this would be a good annotation for a Context because there you >>> could >>> (hopefully) ensure thread safety. For instance you could schedule a >>> recurring method for Context which runs all the diffusion layers in >>> parallel, and then in a second scheduled method you call a method >>> for each >>> agent which calculates and stores a delta based on their current >>> state, >>> notifying observers when they need to examine the object to take >>> action. You >>> could then serially iterate through those actions which need to be >>> done to >>> preserve concurrency and do a mass update on all the rest. >>> >>> Best, >>> RDL >>> >>> -----Original Message----- >>> From: Miles Parker [mailto:mi...@me...] >>> Sent: Friday, September 12, 2008 12:23 AM >>> To: Robert D Leclerc >>> Subject: Re: [Repast-interest] Multithreading and ScheduledMethod >>> >>> >>> Yeah, makes sense. FWIW, the Ascape engine structure is pretty >>> simple >>> and modular so you might play around with the Diffusion rule. >>> Downside >>> is that you can't do arbitrarily scheduled events; this constraint >>> does allow for some efficiencies though, also you have to subclass >>> the >>> Agent class though of course you could always delegate to your own >>> class. >>> >>> Miles' T. Parker >>> Principal >>> Metascape, LLC >>> "Extraordinary Tools for Extraordinary Science" >>> mi...@me... >>> http://metascapeabm.com >>> >>> On Sep 11, 2008, at 9:13 PM, Robert D Leclerc wrote: >>> >>>> Miles, >>>> >>>> No problem. I just posted a note to the RePast forum but it looks >>>> like it'll >>>> be too much effort. I was using repast because (a) the >>>> visualization >>>> capabilities and (b) I thought it had a multithreaded scheduler. >>>> However >>>> since I only need (a) when I am not running in batch mode, and (b) >>>> doesn't >>>> do what I thought, I might try running kludging things together and >>>> running >>>> repast without scheduling the agent behaviour. I can still use the >>>> DiffusionLayer and Grid classes so it's not all bad. >>>> >>>> Best >>>> RDL >>>> >>>> -----Original Message----- >>>> From: Miles Parker [mailto:mi...@me...] >>>> Sent: Friday, September 12, 2008 12:01 AM >>>> To: Robert D Leclerc >>>> Subject: Re: [Repast-interest] Multithreading and ScheduledMethod >>>> >>>> >>>> Hi Robert, >>>> >>>> I should have mentioned that I did that work in Ascape, sorry! The >>>> Simphony architecture is pretty involved. But if you want to see >>>> the >>>> general approach in Ascape, take a look at: >>>> >>>> >>> >> > https://ascape.svn.sourceforge.net/svnroot/ascape/org.ascape.core/src/or > g/as >>>> cape/model/engine/ >>>> >>>> You could start with: >>>> >>>> >>> >> > https://ascape.svn.sourceforge.net/svnroot/ascape/org.ascape.core/src/or > g/as >>>> cape/model/engine/ParallelManager.java >>>> >>>> and for the execute and update.. >>>> >>>> >>> >> > https://ascape.svn.sourceforge.net/svnroot/ascape/org.ascape.core/src/or > g/as >>>> cape/model/rule/ExecuteThenUpdate.java >>>> >>>> Its not as well javadoc'd as I'd like. >>>> >>>> Miles >>>> >>>> On Sep 11, 2008, at 8:31 PM, Robert D Leclerc wrote: >>>> >>>>> Miles >>>>> >>>>> Any chance you have some of the code for that? I really don't want >>>>> to have to implement my code into one of the schedulers. There >>>>> is a >>>>> lot of abstraction, indirection, and call backs and it's not >>>>> always >>>>> easy to tell what is under the hood and how the work flow is >>>>> executed. I think I'll post something to the list to see if >>>>> someone >>>>> is willing to give me a rundown of the Scheduler architecture and >>>>> what pieces I would need to implement. >>>>> >>>>> >>>>> Best, >>>>> >>>>> <image001.png> >>>>> >>>>> Robert D. Leclerc (PhD Fall 08) >>>>> Yale University >>>>> Osborn Memorial Laboratory >>>>> New Haven, CT >>>>> 06520 >>>>> Email: rob...@ya... >>>>> Hompage: http://pantheon.yale.edu/~rdl25/ >>>>> >>>>> -----Original Message----- >>>>> From: Miles Parker [mailto:mil...@gm...] >>>>> Sent: Thursday, September 11, 2008 9:35 PM >>>>> To: Robert D Leclerc >>>>> Cc: rep...@li... >>>>> Subject: Re: [Repast-interest] Multithreading and ScheduledMethod >>>>> >>>>> >>>>> Yes, I see what you mean. ;) I'd take that the same way you did >>>>> -- I >>>>> wasn't really thinking "group concurrent". But the schedule stuff >>>>> is >>>>> pretty deep so I think I'll leave any details on that to Nick. I >>>>> note >>>>> that there is a factory so it might not be that difficult to >>>>> implement >>>>> your own "agent concurrent" schedule. >>>>> >>>>> btw, I've played with an execute/update approach that supports >>>>> what >>>>> you suggest in a more specified way. The idea is that you have an >>>>> "execute" (step) method who's contract is to only gather >>>>> information, >>>>> and an "update" method that can only write state based on prior >>>>> actions. That worked well for diffusion type stuff, but once you >>>>> get >>>>> into movement, its more complicated of course.. One could support >>>>> that >>>>> with annotations as well.. I'll throw my usual saw in here and say >>>>> that one would really like to be able to specify this orthogonally >>>>> to >>>>> the agent specification / classes themselves. >>>>> >>>>> On Sep 11, 2008, at 5:54 PM, Robert D Leclerc wrote: >>>>> >>>>>> Miles, >>>>>> >>>>>> I think I was mislead by the phrase: "A fully concurrent >>>>> multithreaded >>>>>> discrete event scheduler". The way I figured it, you should be >>>>> able to >>>>>> schedule "read/process" methods which can run in parallel, and >>>>>> then >>>>>> at some >>>>>> meet up time you would sequentially call a separate set of >>>>>> stepX() >>>>>> method >>>>>> which need to perform "write" operations. Here it wouldn't be >>>>>> necessary for >>>>>> each agent to have a unique thread, but if you have say 5 threads >>>>>> for each >>>>>> CPU, you should be able to get a lot of work out of it. For >>>>>> instance, if you >>>>>> have several layers doing diffusion, then you could create an >>>>>> agent >>>>>> for each >>>>>> and have them do the diffusion steps in parallel. >>>>>> >>>>>> Turns out I must have been doing something "funny" because I now >>>>>> have the >>>>>> second set of agent groups running concurrently with the first, >>>>>> but >>>>>> I have >>>>>> the problem that any group blocks until the instance is finished >>>>>> with the >>>>>> method. In my model agents need to do some heavy calculations >>>>>> and I >>>>>> thought >>>>>> I could use RePasts concurrency to make my life simpler. >>>>>> >>>>>> Seemingly it would be relatively straightforward to add a >>>>>> variable >>>>>> "concurrentThreads" to the annotation to handle this? I've >>>>>> written >>>>>> some >>>>>> "compute thread" classes which I could probably drop in to a >>>>>> customized >>>>>> scheduling class, but I don't think I have the time to figure out >>>>> the >>>>>> Scheduler code to do it properly. >>>>>> >>>>>> Best, >>>>>> RL >>>>>> >>>>>> -----Original Message----- >>>>>> >>>>>> This seems sensible to me -- all of the ABM environments I'm >>>>>> aware >>>>> of >>>>>> work this way, or should. ;) If this weren't the case, you'd lose >>>>>> repeatability. Properly supporting parallel steps while retaining >>>>>> fully determined behavior is a significant challenge. There was a >>>>>> recent related thread a while ago, I think.. On the other hand if >>>>> you >>>>>> don't care about repeatability this is a totally reasonable thing >>>>>> to >>>>>> want to have as a (non-default) feature. I don't *think* this is >>>>>> the >>>>>> way the Simphony scheduler is supposed to work. Was there >>>>> something in >>>>>> the Simphony docs that made you think that? >>>>>> >>>>>> >>>>>>> I am using RePast Simphony and I would like to execute the >>>>>>> step() >>>>>>> method for >>>>>>> all instances of a given agent class in parallel to take >>>>>>> advantage >>>>>>> of my >>>>>>> multi-core processor, but I seem to be having some trouble >>>>>>> getting >>>>>>> the >>>>>>> scheduler to provide concurrency. >>>>>>> >>>>>>> To test concurrency I annotated the step() method of all my >>>>>>> agent >>>>>>> classes >>>>>>> with: >>>>>>> >>>>>>> @ScheduledMethod(start = 0, duration = 1, interval = 1) >>>>>>> >>>>>>> Then for one of the classes I called Thread.sleep() in its >>>>>>> step() >>>>>>> function: >>>>>>> >>>>>>> @ScheduledMethod(start = 0, duration = 1, interval = 1) >>>>>>> public void someStepMethod(){ >>>>>>> System.out.println("Going to sleep: " + this.toString); >>>>>>> try { >>>>>>> Thread.sleep(3000); >>>>>>> } catch (InterruptedException e) { >>>>>>> e.printStackTrace(); >>>>>>> } >>>>>>> System.out.println("Waking up: " + this.toString); >>>>>>> } >>>>>>> >>>>>>> >>>>>>> When I ran this, I expected that other instances of this agent >>>>> class >>>>>>> would >>>>>>> execute this method in parallel, and that the scheduler would >>>>>>> wait >>>>>>> until >>>>>>> each agent had executed this method before moving on to the next >>>>>>> tick. >>>>>>> However this turned out not to be the case. Rather, calling >>>>>>> Thread.sleep() >>>>>>> blocked all other step() calls, both for instances of this class >>>>>>> as >>>>>>> well as >>>>>>> instances of other classes calling their own step() functions. >>>>>>> >>>>>>> As I understood it, the Scheduler would execute these methods in >>>>>>> their own >>>>>>> threads then wait until all methods were complete before moving >>>>>>> on >>>>>>> to the >>>>>>> next set of ticks. Is there something I am missing or not >>>>> configuring >>>>>>> properly? >>>>>>> >>>>>>> Thanks, >>>>>>> RL >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>> >> > ------------------------------------------------------------------------ > - >>>>>>> This SF.Net email is sponsored by the Moblin Your Move >>>>>>> Developer's >>>>>>> challenge >>>>>>> Build the coolest Linux based applications with Moblin SDK & win >>>>>>> great prizes >>>>>>> Grand prize is a trip for two to an Open Source event anywhere >>>>>>> in >>>>>>> the world >>>>>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >>>>>>> _______________________________________________ >>>>>>> Repast-interest mailing list >>>>>>> Rep...@li... >>>>>>> https://lists.sourceforge.net/lists/listinfo/repast-interest >>>>>> >>>>>> >>>>>> >>>>> >> > ------------------------------------------------------------------------ > - >>>>>> This SF.Net email is sponsored by the Moblin Your Move >>>>>> Developer's >>>>>> challenge >>>>>> Build the coolest Linux based applications with Moblin SDK & win >>>>>> great prizes >>>>>> Grand prize is a trip for two to an Open Source event anywhere in >>>>>> the world >>>>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >>>>>> _______________________________________________ >>>>>> Repast-interest mailing list >>>>>> Rep...@li... >>>>>> https://lists.sourceforge.net/lists/listinfo/repast-interest >>>> >>>> Miles T. Parker >>>> Principal >>>> Metascape, LLC >>>> "Extraordinary Tools for Extraordinary Science" >>>> mi...@me... >>>> http://metascapeabm.com >>>> >>> < >>> ParallelWorkService >>> .java><ParrallelWorkServiceDemo.java><ProxiedMethod.java> >> >> >> > ------------------------------------------------------------------------ > - >> This SF.Net email is sponsored by the Moblin Your Move Developer's >> challenge >> Build the coolest Linux based applications with Moblin SDK & win >> great prizes >> Grand prize is a trip for two to an Open Source event anywhere in >> the world >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> _______________________________________________ >> Repast-developer mailing list >> Rep...@li... >> https://lists.sourceforge.net/lists/listinfo/repast-developer > > > ------------------------------------------------------------------------ > - > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the > world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Repast-developer mailing list > Rep...@li... > https://lists.sourceforge.net/lists/listinfo/repast-developer |
|
From: North, M. <no...@an...> - 2008-09-15 17:46:15
|
I'd like to add that the underlying issues go well beyond Repast, Ascape, or even Java. Fundamentally, it can be challenging to create efficient parallel programs and that even with the best tools only certain limited classes of problems are currently amenable to such implementations. A good resource on the design issues is Ian Foster's "Designing and Building Parallel Programs" web site: http://www-unix.mcs.anl.gov/dbpp/ If an algorithm has poor scalability as defined by Ian's "A Quantitative Basis for Design" chapter (http://tinyurl.com/54r3uc) then no toolkit whether it be in Java 6, Java 7, C/C++. High Performance Fortran or whatever can get it to run efficiently in parallel. Agent-based models that have a large number of agents doing a small amount of work at every time step are likely to fall into the category of poor scalability. Other classes of agent models which have agents doing large amounts of work per time step have at least the potential for, although not the guarantee of, better scalability. Mike -----Original Message----- From: rep...@li... [mailto:rep...@li...] On Behalf Of Robert D Leclerc Sent: Monday, September 15, 2008 9:06 AM To: Collier, Hugh N. Cc: rep...@li...; 'Miles Parker' Subject: Re: [Repast-developer] [Repast-interest] Multithreading andScheduledMethod (References are at end) Supposedly there are significant concurrency additions planned for Java 7 [1-3], so it might be advisable to wait until then. In particular there are plans for adding the "Fork-Join" (FJ) framework [2-4], which uses some special high performance threads [5]. Doug Le mentions that "java.lang.Thread (as well as POSIX pthreads, upon which java threads are based) are sub-optimal for fork-join programs" because these are too heavy for FJ and because FJ tasks never need to block except to wait out sub-tasks" and because they are too heavy. For anyone multithreading your applications, you should read the paper fork-join framework [4]. However, as I discussed earlier, a quick and dirty way to increase performance on a multicore system is to schedule duplicate methods in the Context to run at the same time and the same duration, and maintain your agents in a list so that at some tick t, both methods run concurrently processing separate halves of the list. For example: Class MySpace implements Context{ //Space Details @ScheduleMethod(start=0.1, interval=1, duration=0.1) public void processFirstHalf(){ for(i = 0; i < firstHalf; i++){ agentList.get(i).step(); } } @ScheduleMethod(start=0.1, interval=1, duration=0.1) public void processSecondHalf (){ for(i = firstHalf; i < agentList.size(); i++){ agentList.get(i).step(); } } } Here processFirstHalf() and processSecondHalf() will run concurrently and process agents in parallel. However, you should only be doing this steps which don't affect other agents and each agent could submit themselves to an arbitrator if they require some interaction with the environment or other agents. Also, you need to update the list as you add/remove agents outside of these methods. Using 2 methods might get you about a 50% performance improvement for two threads on a n>1 core system. Moreover, it didn't appear that additional parallelization using n>2 methods helped in a simulation with 900 agents. However, some of this might be due to thread safe collections used by RePast. Best, RDL Some interesting articles I cam across: [1] http://www.infoq.com/news/2007/07/concurrency-java-se-7 [2] http://www.ibm.com/developerworks/java/library/j-jtp11137.html?S_TACT=10 5AGX 02&S_CMP=ART [3] http://www.ibm.com/developerworks/java/library/j-jtp03048.html [4] http://gee.cs.oswego.edu/dl/papers/fj.pdf [5] http://g.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/FJTask.h tml [2] -----Original Message----- From: Nick Collier [mailto:nic...@gm...] Sent: Monday, September 15, 2008 8:53 AM To: Robert D Leclerc Cc: 'Miles Parker'; rep...@li... Subject: Re: [Repast-developer] [Repast-interest] Multithreading and ScheduledMethod Thanks for posting this info. Its been my own experience as well that the threaded tasks need to be few and quite heavy to see any "noticeable" performance improvement. Where I saw the best improvement was with an ant algorithm implementation using many thousands of ants where batches of ants operated in parallel. This also followed the same type of read / update phase that you and Miles mentioned earlier. I had the opposite experience trying to parallelize some shapefile processing code. The complexity of the code became an issue and the performance improvement was in the end too small to justify it. That said, there's probably room for improvement in Repast w/r to Thread creation, pooling and so forth. Parts of the implementation were written before the JDK made such things much easier. Nick On Sep 13, 2008, at 2:49 PM, Robert D Leclerc wrote: > I did some testing with RePasts scheduler as a way to test the > possibility > of using multiple cores (I should have thought about this earlier). > > In the context I cached all the agents to array. In the context I then > created 4 methods that were scheduled at the same time and had the > same > duration. Each of the scheduled methods iterated through a different > section > of the array calling a method on the agent. In this way I could test > how > long it would take to run on my quad core processor. If I used only > one > method to iterate through the whole array, it took 16 seconds. If I > used 2 > methods, each iterating through separate halves, it took 12 seconds. > However, as soon as I tried it with 3 and 4 methods running at the > same > time, it began to take longer than when I used 2 methods running at > the same > time. > > This again suggests that it may be difficult to get RePast (or any > other > Java based ABMS for that matter) to take advantage of multicore > processors > unless it meets some conditions. > > Best, > RDL > > > > > -----Original Message----- > From: Miles Parker [mailto:mi...@ME...] > Sent: Friday, September 12, 2008 4:22 PM > To: Robert D Leclerc > Cc: Nick Collier; rep...@li... > Subject: Re: [Repast-interest] Multithreading and ScheduledMethod > > > [hope you don't mind that I cc'd the develop list] > > Cool. [I wrote the Ascape code before there was all of that nice > built- > in java concurrency stuff. :)] > > That's an important point about using the Context as the point of > action. This is a very logical place for control, but also for > inference! In general, this is true for any collection of agents, e.g. > Scapes, Projections, Swarms..* This is the way that the > parallelization** went down in the Ascape architecture but it is a > consequence of the Scape structure so it isn't really obvious. You > have Scape grained control over the style of execution. The Strategy > factory will make inferences about the scape's rules sets and > determine wether it it reasonable to try to run some rules in > parallel. > > For example, if you have a Scape Array with a Diffusion rule the > framework will know that it is safe to run in parallel. This is > because Diffusion returns false for "isRandomExecution" which means > that it does not have an effect on its neighbors that needs to happen > in any particular order. And since Array is immutable we know that we > don't need to worry about the population size changing. > > For the Scape Population, those qualities would not hold true because > spatial individual effects mean that order does matter. But one could > imagine using richer semantics allowing the kinds of thing you're > suggesting below. > > So while it makes sense to have intelligence at the Context/ > collection/ > Scape level, schedule annotations on context alone would maybe not be > granular/rich enough at this point. > > *btw, I'm moving back to the view that there is a role for a > scaffolding Scape structure in the ABM meta-model collaborating w/ > Context and Projections. I'm going to play around a bit with this as > there seems to be some kind of generic unified model lurking in there > somewhere. Thoughts anyone? > > **LOL, I horribly misspelled "Parallelization" and when I clicked on > the Apple Mail Spell Check the only thing it could come up with was > "Paralyzation"! > > > Miles T. Parker > Principal > Metascape, LLC > "Extraordinary Tools for Extraordinary Science" > mi...@me... > http://metascapeabm.com > > On Sep 12, 2008, at 11:15 AM, Robert D Leclerc wrote: > >> Miles, >> >> If you are interested, I attached a WorkerService class which can be >> easily >> dropped into RePast. This will allow you to create n number of worker >> threads which execute a method on a set of objects, and blocking >> until all >> the objects have evoked and returned from their method calls. You can >> specify which method to execute in the constructor by either (a) >> specifying >> the class and method name for the object type, or (b) implementing a >> ProxiedMethod interface which makes the specific method call. >> >> ParallelWorkServiceDemo (attached) has a very short example and you >> can >> basically use this with 2 lines of code, and not worry about it as >> long as >> you are not doing anything else at this time. >> >> Nick emailed me also, so I sent him this code as well in case he >> finds some >> use for it in future versions of the scheduler. It would seem to me >> that >> this would be a good annotation for a Context because there you could >> (hopefully) ensure thread safety. For instance you could schedule a >> recurring method for Context which runs all the diffusion layers in >> parallel, and then in a second scheduled method you call a method >> for each >> agent which calculates and stores a delta based on their current >> state, >> notifying observers when they need to examine the object to take >> action. You >> could then serially iterate through those actions which need to be >> done to >> preserve concurrency and do a mass update on all the rest. >> >> Best, >> RDL >> >> -----Original Message----- >> From: Miles Parker [mailto:mi...@me...] >> Sent: Friday, September 12, 2008 12:23 AM >> To: Robert D Leclerc >> Subject: Re: [Repast-interest] Multithreading and ScheduledMethod >> >> >> Yeah, makes sense. FWIW, the Ascape engine structure is pretty simple >> and modular so you might play around with the Diffusion rule. >> Downside >> is that you can't do arbitrarily scheduled events; this constraint >> does allow for some efficiencies though, also you have to subclass >> the >> Agent class though of course you could always delegate to your own >> class. >> >> Miles' T. Parker >> Principal >> Metascape, LLC >> "Extraordinary Tools for Extraordinary Science" >> mi...@me... >> http://metascapeabm.com >> >> On Sep 11, 2008, at 9:13 PM, Robert D Leclerc wrote: >> >>> Miles, >>> >>> No problem. I just posted a note to the RePast forum but it looks >>> like it'll >>> be too much effort. I was using repast because (a) the visualization >>> capabilities and (b) I thought it had a multithreaded scheduler. >>> However >>> since I only need (a) when I am not running in batch mode, and (b) >>> doesn't >>> do what I thought, I might try running kludging things together and >>> running >>> repast without scheduling the agent behaviour. I can still use the >>> DiffusionLayer and Grid classes so it's not all bad. >>> >>> Best >>> RDL >>> >>> -----Original Message----- >>> From: Miles Parker [mailto:mi...@me...] >>> Sent: Friday, September 12, 2008 12:01 AM >>> To: Robert D Leclerc >>> Subject: Re: [Repast-interest] Multithreading and ScheduledMethod >>> >>> >>> Hi Robert, >>> >>> I should have mentioned that I did that work in Ascape, sorry! The >>> Simphony architecture is pretty involved. But if you want to see the >>> general approach in Ascape, take a look at: >>> >>> >> > https://ascape.svn.sourceforge.net/svnroot/ascape/org.ascape.core/src/or g/as >>> cape/model/engine/ >>> >>> You could start with: >>> >>> >> > https://ascape.svn.sourceforge.net/svnroot/ascape/org.ascape.core/src/or g/as >>> cape/model/engine/ParallelManager.java >>> >>> and for the execute and update.. >>> >>> >> > https://ascape.svn.sourceforge.net/svnroot/ascape/org.ascape.core/src/or g/as >>> cape/model/rule/ExecuteThenUpdate.java >>> >>> Its not as well javadoc'd as I'd like. >>> >>> Miles >>> >>> On Sep 11, 2008, at 8:31 PM, Robert D Leclerc wrote: >>> >>>> Miles >>>> >>>> Any chance you have some of the code for that? I really don't want >>>> to have to implement my code into one of the schedulers. There is a >>>> lot of abstraction, indirection, and call backs and it's not always >>>> easy to tell what is under the hood and how the work flow is >>>> executed. I think I'll post something to the list to see if someone >>>> is willing to give me a rundown of the Scheduler architecture and >>>> what pieces I would need to implement. >>>> >>>> >>>> Best, >>>> >>>> <image001.png> >>>> >>>> Robert D. Leclerc (PhD Fall 08) >>>> Yale University >>>> Osborn Memorial Laboratory >>>> New Haven, CT >>>> 06520 >>>> Email: rob...@ya... >>>> Hompage: http://pantheon.yale.edu/~rdl25/ >>>> >>>> -----Original Message----- >>>> From: Miles Parker [mailto:mil...@gm...] >>>> Sent: Thursday, September 11, 2008 9:35 PM >>>> To: Robert D Leclerc >>>> Cc: rep...@li... >>>> Subject: Re: [Repast-interest] Multithreading and ScheduledMethod >>>> >>>> >>>> Yes, I see what you mean. ;) I'd take that the same way you did >>>> -- I >>>> wasn't really thinking "group concurrent". But the schedule stuff >>>> is >>>> pretty deep so I think I'll leave any details on that to Nick. I >>>> note >>>> that there is a factory so it might not be that difficult to >>>> implement >>>> your own "agent concurrent" schedule. >>>> >>>> btw, I've played with an execute/update approach that supports what >>>> you suggest in a more specified way. The idea is that you have an >>>> "execute" (step) method who's contract is to only gather >>>> information, >>>> and an "update" method that can only write state based on prior >>>> actions. That worked well for diffusion type stuff, but once you >>>> get >>>> into movement, its more complicated of course.. One could support >>>> that >>>> with annotations as well.. I'll throw my usual saw in here and say >>>> that one would really like to be able to specify this orthogonally >>>> to >>>> the agent specification / classes themselves. >>>> >>>> On Sep 11, 2008, at 5:54 PM, Robert D Leclerc wrote: >>>> >>>>> Miles, >>>>> >>>>> I think I was mislead by the phrase: "A fully concurrent >>>> multithreaded >>>>> discrete event scheduler". The way I figured it, you should be >>>> able to >>>>> schedule "read/process" methods which can run in parallel, and >>>>> then >>>>> at some >>>>> meet up time you would sequentially call a separate set of stepX() >>>>> method >>>>> which need to perform "write" operations. Here it wouldn't be >>>>> necessary for >>>>> each agent to have a unique thread, but if you have say 5 threads >>>>> for each >>>>> CPU, you should be able to get a lot of work out of it. For >>>>> instance, if you >>>>> have several layers doing diffusion, then you could create an >>>>> agent >>>>> for each >>>>> and have them do the diffusion steps in parallel. >>>>> >>>>> Turns out I must have been doing something "funny" because I now >>>>> have the >>>>> second set of agent groups running concurrently with the first, >>>>> but >>>>> I have >>>>> the problem that any group blocks until the instance is finished >>>>> with the >>>>> method. In my model agents need to do some heavy calculations >>>>> and I >>>>> thought >>>>> I could use RePasts concurrency to make my life simpler. >>>>> >>>>> Seemingly it would be relatively straightforward to add a variable >>>>> "concurrentThreads" to the annotation to handle this? I've written >>>>> some >>>>> "compute thread" classes which I could probably drop in to a >>>>> customized >>>>> scheduling class, but I don't think I have the time to figure out >>>> the >>>>> Scheduler code to do it properly. >>>>> >>>>> Best, >>>>> RL >>>>> >>>>> -----Original Message----- >>>>> >>>>> This seems sensible to me -- all of the ABM environments I'm aware >>>> of >>>>> work this way, or should. ;) If this weren't the case, you'd lose >>>>> repeatability. Properly supporting parallel steps while retaining >>>>> fully determined behavior is a significant challenge. There was a >>>>> recent related thread a while ago, I think.. On the other hand if >>>> you >>>>> don't care about repeatability this is a totally reasonable thing >>>>> to >>>>> want to have as a (non-default) feature. I don't *think* this is >>>>> the >>>>> way the Simphony scheduler is supposed to work. Was there >>>> something in >>>>> the Simphony docs that made you think that? >>>>> >>>>> >>>>>> I am using RePast Simphony and I would like to execute the step() >>>>>> method for >>>>>> all instances of a given agent class in parallel to take >>>>>> advantage >>>>>> of my >>>>>> multi-core processor, but I seem to be having some trouble >>>>>> getting >>>>>> the >>>>>> scheduler to provide concurrency. >>>>>> >>>>>> To test concurrency I annotated the step() method of all my agent >>>>>> classes >>>>>> with: >>>>>> >>>>>> @ScheduledMethod(start = 0, duration = 1, interval = 1) >>>>>> >>>>>> Then for one of the classes I called Thread.sleep() in its step() >>>>>> function: >>>>>> >>>>>> @ScheduledMethod(start = 0, duration = 1, interval = 1) >>>>>> public void someStepMethod(){ >>>>>> System.out.println("Going to sleep: " + this.toString); >>>>>> try { >>>>>> Thread.sleep(3000); >>>>>> } catch (InterruptedException e) { >>>>>> e.printStackTrace(); >>>>>> } >>>>>> System.out.println("Waking up: " + this.toString); >>>>>> } >>>>>> >>>>>> >>>>>> When I ran this, I expected that other instances of this agent >>>> class >>>>>> would >>>>>> execute this method in parallel, and that the scheduler would >>>>>> wait >>>>>> until >>>>>> each agent had executed this method before moving on to the next >>>>>> tick. >>>>>> However this turned out not to be the case. Rather, calling >>>>>> Thread.sleep() >>>>>> blocked all other step() calls, both for instances of this class >>>>>> as >>>>>> well as >>>>>> instances of other classes calling their own step() functions. >>>>>> >>>>>> As I understood it, the Scheduler would execute these methods in >>>>>> their own >>>>>> threads then wait until all methods were complete before moving >>>>>> on >>>>>> to the >>>>>> next set of ticks. Is there something I am missing or not >>>> configuring >>>>>> properly? >>>>>> >>>>>> Thanks, >>>>>> RL >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>> > ------------------------------------------------------------------------ - >>>>>> This SF.Net email is sponsored by the Moblin Your Move >>>>>> Developer's >>>>>> challenge >>>>>> Build the coolest Linux based applications with Moblin SDK & win >>>>>> great prizes >>>>>> Grand prize is a trip for two to an Open Source event anywhere in >>>>>> the world >>>>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >>>>>> _______________________________________________ >>>>>> Repast-interest mailing list >>>>>> Rep...@li... >>>>>> https://lists.sourceforge.net/lists/listinfo/repast-interest >>>>> >>>>> >>>>> >>>> > ------------------------------------------------------------------------ - >>>>> This SF.Net email is sponsored by the Moblin Your Move Developer's >>>>> challenge >>>>> Build the coolest Linux based applications with Moblin SDK & win >>>>> great prizes >>>>> Grand prize is a trip for two to an Open Source event anywhere in >>>>> the world >>>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >>>>> _______________________________________________ >>>>> Repast-interest mailing list >>>>> Rep...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/repast-interest >>> >>> Miles T. Parker >>> Principal >>> Metascape, LLC >>> "Extraordinary Tools for Extraordinary Science" >>> mi...@me... >>> http://metascapeabm.com >>> >> < >> ParallelWorkService >> .java><ParrallelWorkServiceDemo.java><ProxiedMethod.java> > > > ------------------------------------------------------------------------ - > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win > great prizes > Grand prize is a trip for two to an Open Source event anywhere in > the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Repast-developer mailing list > Rep...@li... > https://lists.sourceforge.net/lists/listinfo/repast-developer ------------------------------------------------------------------------ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Repast-developer mailing list Rep...@li... https://lists.sourceforge.net/lists/listinfo/repast-developer |
|
From: Robert D L. <rob...@ya...> - 2008-09-15 14:06:09
|
(References are at end)
Supposedly there are significant concurrency additions planned for Java 7
[1-3], so it might be advisable to wait until then. In particular there are
plans for adding the "Fork-Join" (FJ) framework [2-4], which uses some
special high performance threads [5]. Doug Le mentions that
"java.lang.Thread (as well as POSIX pthreads, upon which java threads are
based) are sub-optimal for fork-join programs" because these are too heavy
for FJ and because FJ tasks never need to block except to wait out
sub-tasks" and because they are too heavy.
For anyone multithreading your applications, you should read the paper
fork-join framework [4]. However, as I discussed earlier, a quick and dirty
way to increase performance on a multicore system is to schedule duplicate
methods in the Context to run at the same time and the same duration, and
maintain your agents in a list so that at some tick t, both methods run
concurrently processing separate halves of the list. For example:
Class MySpace implements Context{
//Space Details
@ScheduleMethod(start=0.1, interval=1, duration=0.1)
public void processFirstHalf(){
for(i = 0; i < firstHalf; i++){
agentList.get(i).step();
}
}
@ScheduleMethod(start=0.1, interval=1, duration=0.1)
public void processSecondHalf (){
for(i = firstHalf; i < agentList.size(); i++){
agentList.get(i).step();
}
}
}
Here processFirstHalf() and processSecondHalf() will run concurrently and
process agents in parallel.
However, you should only be doing this steps which don't affect other agents
and each agent could submit themselves to an arbitrator if they require some
interaction with the environment or other agents. Also, you need to update
the list as you add/remove agents outside of these methods. Using 2 methods
might get you about a 50% performance improvement for two threads on a n>1
core system. Moreover, it didn't appear that additional parallelization
using n>2 methods helped in a simulation with 900 agents. However, some of
this might be due to thread safe collections used by RePast.
Best,
RDL
Some interesting articles I cam across:
[1] http://www.infoq.com/news/2007/07/concurrency-java-se-7
[2]
http://www.ibm.com/developerworks/java/library/j-jtp11137.html?S_TACT=105AGX
02&S_CMP=ART
[3] http://www.ibm.com/developerworks/java/library/j-jtp03048.html
[4] http://gee.cs.oswego.edu/dl/papers/fj.pdf
[5]
http://g.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/FJTask.html
[2]
-----Original Message-----
From: Nick Collier [mailto:nic...@gm...]
Sent: Monday, September 15, 2008 8:53 AM
To: Robert D Leclerc
Cc: 'Miles Parker'; rep...@li...
Subject: Re: [Repast-developer] [Repast-interest] Multithreading and
ScheduledMethod
Thanks for posting this info. Its been my own experience as well that
the threaded tasks need to be few and quite heavy to see any
"noticeable" performance improvement. Where I saw the best improvement
was with an ant algorithm implementation using many thousands of ants
where batches of ants operated in parallel. This also followed the
same type of read / update phase that you and Miles mentioned earlier.
I had the opposite experience trying to parallelize some shapefile
processing code. The complexity of the code became an issue and the
performance improvement was in the end too small to justify it.
That said, there's probably room for improvement in Repast w/r to
Thread creation, pooling and so forth. Parts of the implementation
were written before the JDK made such things much easier.
Nick
On Sep 13, 2008, at 2:49 PM, Robert D Leclerc wrote:
> I did some testing with RePasts scheduler as a way to test the
> possibility
> of using multiple cores (I should have thought about this earlier).
>
> In the context I cached all the agents to array. In the context I then
> created 4 methods that were scheduled at the same time and had the
> same
> duration. Each of the scheduled methods iterated through a different
> section
> of the array calling a method on the agent. In this way I could test
> how
> long it would take to run on my quad core processor. If I used only
> one
> method to iterate through the whole array, it took 16 seconds. If I
> used 2
> methods, each iterating through separate halves, it took 12 seconds.
> However, as soon as I tried it with 3 and 4 methods running at the
> same
> time, it began to take longer than when I used 2 methods running at
> the same
> time.
>
> This again suggests that it may be difficult to get RePast (or any
> other
> Java based ABMS for that matter) to take advantage of multicore
> processors
> unless it meets some conditions.
>
> Best,
> RDL
>
>
>
>
> -----Original Message-----
> From: Miles Parker [mailto:mi...@ME...]
> Sent: Friday, September 12, 2008 4:22 PM
> To: Robert D Leclerc
> Cc: Nick Collier; rep...@li...
> Subject: Re: [Repast-interest] Multithreading and ScheduledMethod
>
>
> [hope you don't mind that I cc'd the develop list]
>
> Cool. [I wrote the Ascape code before there was all of that nice
> built-
> in java concurrency stuff. :)]
>
> That's an important point about using the Context as the point of
> action. This is a very logical place for control, but also for
> inference! In general, this is true for any collection of agents, e.g.
> Scapes, Projections, Swarms..* This is the way that the
> parallelization** went down in the Ascape architecture but it is a
> consequence of the Scape structure so it isn't really obvious. You
> have Scape grained control over the style of execution. The Strategy
> factory will make inferences about the scape's rules sets and
> determine wether it it reasonable to try to run some rules in
> parallel.
>
> For example, if you have a Scape Array with a Diffusion rule the
> framework will know that it is safe to run in parallel. This is
> because Diffusion returns false for "isRandomExecution" which means
> that it does not have an effect on its neighbors that needs to happen
> in any particular order. And since Array is immutable we know that we
> don't need to worry about the population size changing.
>
> For the Scape Population, those qualities would not hold true because
> spatial individual effects mean that order does matter. But one could
> imagine using richer semantics allowing the kinds of thing you're
> suggesting below.
>
> So while it makes sense to have intelligence at the Context/
> collection/
> Scape level, schedule annotations on context alone would maybe not be
> granular/rich enough at this point.
>
> *btw, I'm moving back to the view that there is a role for a
> scaffolding Scape structure in the ABM meta-model collaborating w/
> Context and Projections. I'm going to play around a bit with this as
> there seems to be some kind of generic unified model lurking in there
> somewhere. Thoughts anyone?
>
> **LOL, I horribly misspelled "Parallelization" and when I clicked on
> the Apple Mail Spell Check the only thing it could come up with was
> "Paralyzation"!
>
>
> Miles T. Parker
> Principal
> Metascape, LLC
> "Extraordinary Tools for Extraordinary Science"
> mi...@me...
> http://metascapeabm.com
>
> On Sep 12, 2008, at 11:15 AM, Robert D Leclerc wrote:
>
>> Miles,
>>
>> If you are interested, I attached a WorkerService class which can be
>> easily
>> dropped into RePast. This will allow you to create n number of worker
>> threads which execute a method on a set of objects, and blocking
>> until all
>> the objects have evoked and returned from their method calls. You can
>> specify which method to execute in the constructor by either (a)
>> specifying
>> the class and method name for the object type, or (b) implementing a
>> ProxiedMethod interface which makes the specific method call.
>>
>> ParallelWorkServiceDemo (attached) has a very short example and you
>> can
>> basically use this with 2 lines of code, and not worry about it as
>> long as
>> you are not doing anything else at this time.
>>
>> Nick emailed me also, so I sent him this code as well in case he
>> finds some
>> use for it in future versions of the scheduler. It would seem to me
>> that
>> this would be a good annotation for a Context because there you could
>> (hopefully) ensure thread safety. For instance you could schedule a
>> recurring method for Context which runs all the diffusion layers in
>> parallel, and then in a second scheduled method you call a method
>> for each
>> agent which calculates and stores a delta based on their current
>> state,
>> notifying observers when they need to examine the object to take
>> action. You
>> could then serially iterate through those actions which need to be
>> done to
>> preserve concurrency and do a mass update on all the rest.
>>
>> Best,
>> RDL
>>
>> -----Original Message-----
>> From: Miles Parker [mailto:mi...@me...]
>> Sent: Friday, September 12, 2008 12:23 AM
>> To: Robert D Leclerc
>> Subject: Re: [Repast-interest] Multithreading and ScheduledMethod
>>
>>
>> Yeah, makes sense. FWIW, the Ascape engine structure is pretty simple
>> and modular so you might play around with the Diffusion rule.
>> Downside
>> is that you can't do arbitrarily scheduled events; this constraint
>> does allow for some efficiencies though, also you have to subclass
>> the
>> Agent class though of course you could always delegate to your own
>> class.
>>
>> Miles' T. Parker
>> Principal
>> Metascape, LLC
>> "Extraordinary Tools for Extraordinary Science"
>> mi...@me...
>> http://metascapeabm.com
>>
>> On Sep 11, 2008, at 9:13 PM, Robert D Leclerc wrote:
>>
>>> Miles,
>>>
>>> No problem. I just posted a note to the RePast forum but it looks
>>> like it'll
>>> be too much effort. I was using repast because (a) the visualization
>>> capabilities and (b) I thought it had a multithreaded scheduler.
>>> However
>>> since I only need (a) when I am not running in batch mode, and (b)
>>> doesn't
>>> do what I thought, I might try running kludging things together and
>>> running
>>> repast without scheduling the agent behaviour. I can still use the
>>> DiffusionLayer and Grid classes so it's not all bad.
>>>
>>> Best
>>> RDL
>>>
>>> -----Original Message-----
>>> From: Miles Parker [mailto:mi...@me...]
>>> Sent: Friday, September 12, 2008 12:01 AM
>>> To: Robert D Leclerc
>>> Subject: Re: [Repast-interest] Multithreading and ScheduledMethod
>>>
>>>
>>> Hi Robert,
>>>
>>> I should have mentioned that I did that work in Ascape, sorry! The
>>> Simphony architecture is pretty involved. But if you want to see the
>>> general approach in Ascape, take a look at:
>>>
>>>
>>
>
https://ascape.svn.sourceforge.net/svnroot/ascape/org.ascape.core/src/org/as
>>> cape/model/engine/
>>>
>>> You could start with:
>>>
>>>
>>
>
https://ascape.svn.sourceforge.net/svnroot/ascape/org.ascape.core/src/org/as
>>> cape/model/engine/ParallelManager.java
>>>
>>> and for the execute and update..
>>>
>>>
>>
>
https://ascape.svn.sourceforge.net/svnroot/ascape/org.ascape.core/src/org/as
>>> cape/model/rule/ExecuteThenUpdate.java
>>>
>>> Its not as well javadoc'd as I'd like.
>>>
>>> Miles
>>>
>>> On Sep 11, 2008, at 8:31 PM, Robert D Leclerc wrote:
>>>
>>>> Miles
>>>>
>>>> Any chance you have some of the code for that? I really don't want
>>>> to have to implement my code into one of the schedulers. There is a
>>>> lot of abstraction, indirection, and call backs and it's not always
>>>> easy to tell what is under the hood and how the work flow is
>>>> executed. I think I'll post something to the list to see if someone
>>>> is willing to give me a rundown of the Scheduler architecture and
>>>> what pieces I would need to implement.
>>>>
>>>>
>>>> Best,
>>>>
>>>> <image001.png>
>>>>
>>>> Robert D. Leclerc (PhD Fall 08)
>>>> Yale University
>>>> Osborn Memorial Laboratory
>>>> New Haven, CT
>>>> 06520
>>>> Email: rob...@ya...
>>>> Hompage: http://pantheon.yale.edu/~rdl25/
>>>>
>>>> -----Original Message-----
>>>> From: Miles Parker [mailto:mil...@gm...]
>>>> Sent: Thursday, September 11, 2008 9:35 PM
>>>> To: Robert D Leclerc
>>>> Cc: rep...@li...
>>>> Subject: Re: [Repast-interest] Multithreading and ScheduledMethod
>>>>
>>>>
>>>> Yes, I see what you mean. ;) I'd take that the same way you did
>>>> -- I
>>>> wasn't really thinking "group concurrent". But the schedule stuff
>>>> is
>>>> pretty deep so I think I'll leave any details on that to Nick. I
>>>> note
>>>> that there is a factory so it might not be that difficult to
>>>> implement
>>>> your own "agent concurrent" schedule.
>>>>
>>>> btw, I've played with an execute/update approach that supports what
>>>> you suggest in a more specified way. The idea is that you have an
>>>> "execute" (step) method who's contract is to only gather
>>>> information,
>>>> and an "update" method that can only write state based on prior
>>>> actions. That worked well for diffusion type stuff, but once you
>>>> get
>>>> into movement, its more complicated of course.. One could support
>>>> that
>>>> with annotations as well.. I'll throw my usual saw in here and say
>>>> that one would really like to be able to specify this orthogonally
>>>> to
>>>> the agent specification / classes themselves.
>>>>
>>>> On Sep 11, 2008, at 5:54 PM, Robert D Leclerc wrote:
>>>>
>>>>> Miles,
>>>>>
>>>>> I think I was mislead by the phrase: "A fully concurrent
>>>> multithreaded
>>>>> discrete event scheduler". The way I figured it, you should be
>>>> able to
>>>>> schedule "read/process" methods which can run in parallel, and
>>>>> then
>>>>> at some
>>>>> meet up time you would sequentially call a separate set of stepX()
>>>>> method
>>>>> which need to perform "write" operations. Here it wouldn't be
>>>>> necessary for
>>>>> each agent to have a unique thread, but if you have say 5 threads
>>>>> for each
>>>>> CPU, you should be able to get a lot of work out of it. For
>>>>> instance, if you
>>>>> have several layers doing diffusion, then you could create an
>>>>> agent
>>>>> for each
>>>>> and have them do the diffusion steps in parallel.
>>>>>
>>>>> Turns out I must have been doing something "funny" because I now
>>>>> have the
>>>>> second set of agent groups running concurrently with the first,
>>>>> but
>>>>> I have
>>>>> the problem that any group blocks until the instance is finished
>>>>> with the
>>>>> method. In my model agents need to do some heavy calculations
>>>>> and I
>>>>> thought
>>>>> I could use RePasts concurrency to make my life simpler.
>>>>>
>>>>> Seemingly it would be relatively straightforward to add a variable
>>>>> "concurrentThreads" to the annotation to handle this? I've written
>>>>> some
>>>>> "compute thread" classes which I could probably drop in to a
>>>>> customized
>>>>> scheduling class, but I don't think I have the time to figure out
>>>> the
>>>>> Scheduler code to do it properly.
>>>>>
>>>>> Best,
>>>>> RL
>>>>>
>>>>> -----Original Message-----
>>>>>
>>>>> This seems sensible to me -- all of the ABM environments I'm aware
>>>> of
>>>>> work this way, or should. ;) If this weren't the case, you'd lose
>>>>> repeatability. Properly supporting parallel steps while retaining
>>>>> fully determined behavior is a significant challenge. There was a
>>>>> recent related thread a while ago, I think.. On the other hand if
>>>> you
>>>>> don't care about repeatability this is a totally reasonable thing
>>>>> to
>>>>> want to have as a (non-default) feature. I don't *think* this is
>>>>> the
>>>>> way the Simphony scheduler is supposed to work. Was there
>>>> something in
>>>>> the Simphony docs that made you think that?
>>>>>
>>>>>
>>>>>> I am using RePast Simphony and I would like to execute the step()
>>>>>> method for
>>>>>> all instances of a given agent class in parallel to take
>>>>>> advantage
>>>>>> of my
>>>>>> multi-core processor, but I seem to be having some trouble
>>>>>> getting
>>>>>> the
>>>>>> scheduler to provide concurrency.
>>>>>>
>>>>>> To test concurrency I annotated the step() method of all my agent
>>>>>> classes
>>>>>> with:
>>>>>>
>>>>>> @ScheduledMethod(start = 0, duration = 1, interval = 1)
>>>>>>
>>>>>> Then for one of the classes I called Thread.sleep() in its step()
>>>>>> function:
>>>>>>
>>>>>> @ScheduledMethod(start = 0, duration = 1, interval = 1)
>>>>>> public void someStepMethod(){
>>>>>> System.out.println("Going to sleep: " + this.toString);
>>>>>> try {
>>>>>> Thread.sleep(3000);
>>>>>> } catch (InterruptedException e) {
>>>>>> e.printStackTrace();
>>>>>> }
>>>>>> System.out.println("Waking up: " + this.toString);
>>>>>> }
>>>>>>
>>>>>>
>>>>>> When I ran this, I expected that other instances of this agent
>>>> class
>>>>>> would
>>>>>> execute this method in parallel, and that the scheduler would
>>>>>> wait
>>>>>> until
>>>>>> each agent had executed this method before moving on to the next
>>>>>> tick.
>>>>>> However this turned out not to be the case. Rather, calling
>>>>>> Thread.sleep()
>>>>>> blocked all other step() calls, both for instances of this class
>>>>>> as
>>>>>> well as
>>>>>> instances of other classes calling their own step() functions.
>>>>>>
>>>>>> As I understood it, the Scheduler would execute these methods in
>>>>>> their own
>>>>>> threads then wait until all methods were complete before moving
>>>>>> on
>>>>>> to the
>>>>>> next set of ticks. Is there something I am missing or not
>>>> configuring
>>>>>> properly?
>>>>>>
>>>>>> Thanks,
>>>>>> RL
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
> -------------------------------------------------------------------------
>>>>>> This SF.Net email is sponsored by the Moblin Your Move
>>>>>> Developer's
>>>>>> challenge
>>>>>> Build the coolest Linux based applications with Moblin SDK & win
>>>>>> great prizes
>>>>>> Grand prize is a trip for two to an Open Source event anywhere in
>>>>>> the world
>>>>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>>>>> _______________________________________________
>>>>>> Repast-interest mailing list
>>>>>> Rep...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/repast-interest
>>>>>
>>>>>
>>>>>
>>>>
> -------------------------------------------------------------------------
>>>>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>>>>> challenge
>>>>> Build the coolest Linux based applications with Moblin SDK & win
>>>>> great prizes
>>>>> Grand prize is a trip for two to an Open Source event anywhere in
>>>>> the world
>>>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>>>> _______________________________________________
>>>>> Repast-interest mailing list
>>>>> Rep...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/repast-interest
>>>
>>> Miles T. Parker
>>> Principal
>>> Metascape, LLC
>>> "Extraordinary Tools for Extraordinary Science"
>>> mi...@me...
>>> http://metascapeabm.com
>>>
>> <
>> ParallelWorkService
>> .java><ParrallelWorkServiceDemo.java><ProxiedMethod.java>
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win
> great prizes
> Grand prize is a trip for two to an Open Source event anywhere in
> the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Repast-developer mailing list
> Rep...@li...
> https://lists.sourceforge.net/lists/listinfo/repast-developer
|
|
From: Nick C. <nic...@gm...> - 2008-09-15 12:52:58
|
Thanks for posting this info. Its been my own experience as well that the threaded tasks need to be few and quite heavy to see any "noticeable" performance improvement. Where I saw the best improvement was with an ant algorithm implementation using many thousands of ants where batches of ants operated in parallel. This also followed the same type of read / update phase that you and Miles mentioned earlier. I had the opposite experience trying to parallelize some shapefile processing code. The complexity of the code became an issue and the performance improvement was in the end too small to justify it. That said, there's probably room for improvement in Repast w/r to Thread creation, pooling and so forth. Parts of the implementation were written before the JDK made such things much easier. Nick On Sep 13, 2008, at 2:49 PM, Robert D Leclerc wrote: > I did some testing with RePasts scheduler as a way to test the > possibility > of using multiple cores (I should have thought about this earlier). > > In the context I cached all the agents to array. In the context I then > created 4 methods that were scheduled at the same time and had the > same > duration. Each of the scheduled methods iterated through a different > section > of the array calling a method on the agent. In this way I could test > how > long it would take to run on my quad core processor. If I used only > one > method to iterate through the whole array, it took 16 seconds. If I > used 2 > methods, each iterating through separate halves, it took 12 seconds. > However, as soon as I tried it with 3 and 4 methods running at the > same > time, it began to take longer than when I used 2 methods running at > the same > time. > > This again suggests that it may be difficult to get RePast (or any > other > Java based ABMS for that matter) to take advantage of multicore > processors > unless it meets some conditions. > > Best, > RDL > > > > > -----Original Message----- > From: Miles Parker [mailto:mi...@ME...] > Sent: Friday, September 12, 2008 4:22 PM > To: Robert D Leclerc > Cc: Nick Collier; rep...@li... > Subject: Re: [Repast-interest] Multithreading and ScheduledMethod > > > [hope you don't mind that I cc'd the develop list] > > Cool. [I wrote the Ascape code before there was all of that nice > built- > in java concurrency stuff. :)] > > That's an important point about using the Context as the point of > action. This is a very logical place for control, but also for > inference! In general, this is true for any collection of agents, e.g. > Scapes, Projections, Swarms..* This is the way that the > parallelization** went down in the Ascape architecture but it is a > consequence of the Scape structure so it isn't really obvious. You > have Scape grained control over the style of execution. The Strategy > factory will make inferences about the scape's rules sets and > determine wether it it reasonable to try to run some rules in > parallel. > > For example, if you have a Scape Array with a Diffusion rule the > framework will know that it is safe to run in parallel. This is > because Diffusion returns false for "isRandomExecution" which means > that it does not have an effect on its neighbors that needs to happen > in any particular order. And since Array is immutable we know that we > don't need to worry about the population size changing. > > For the Scape Population, those qualities would not hold true because > spatial individual effects mean that order does matter. But one could > imagine using richer semantics allowing the kinds of thing you're > suggesting below. > > So while it makes sense to have intelligence at the Context/ > collection/ > Scape level, schedule annotations on context alone would maybe not be > granular/rich enough at this point. > > *btw, I'm moving back to the view that there is a role for a > scaffolding Scape structure in the ABM meta-model collaborating w/ > Context and Projections. I'm going to play around a bit with this as > there seems to be some kind of generic unified model lurking in there > somewhere. Thoughts anyone? > > **LOL, I horribly misspelled "Parallelization" and when I clicked on > the Apple Mail Spell Check the only thing it could come up with was > "Paralyzation"! > > > Miles T. Parker > Principal > Metascape, LLC > "Extraordinary Tools for Extraordinary Science" > mi...@me... > http://metascapeabm.com > > On Sep 12, 2008, at 11:15 AM, Robert D Leclerc wrote: > >> Miles, >> >> If you are interested, I attached a WorkerService class which can be >> easily >> dropped into RePast. This will allow you to create n number of worker >> threads which execute a method on a set of objects, and blocking >> until all >> the objects have evoked and returned from their method calls. You can >> specify which method to execute in the constructor by either (a) >> specifying >> the class and method name for the object type, or (b) implementing a >> ProxiedMethod interface which makes the specific method call. >> >> ParallelWorkServiceDemo (attached) has a very short example and you >> can >> basically use this with 2 lines of code, and not worry about it as >> long as >> you are not doing anything else at this time. >> >> Nick emailed me also, so I sent him this code as well in case he >> finds some >> use for it in future versions of the scheduler. It would seem to me >> that >> this would be a good annotation for a Context because there you could >> (hopefully) ensure thread safety. For instance you could schedule a >> recurring method for Context which runs all the diffusion layers in >> parallel, and then in a second scheduled method you call a method >> for each >> agent which calculates and stores a delta based on their current >> state, >> notifying observers when they need to examine the object to take >> action. You >> could then serially iterate through those actions which need to be >> done to >> preserve concurrency and do a mass update on all the rest. >> >> Best, >> RDL >> >> -----Original Message----- >> From: Miles Parker [mailto:mi...@me...] >> Sent: Friday, September 12, 2008 12:23 AM >> To: Robert D Leclerc >> Subject: Re: [Repast-interest] Multithreading and ScheduledMethod >> >> >> Yeah, makes sense. FWIW, the Ascape engine structure is pretty simple >> and modular so you might play around with the Diffusion rule. >> Downside >> is that you can't do arbitrarily scheduled events; this constraint >> does allow for some efficiencies though, also you have to subclass >> the >> Agent class though of course you could always delegate to your own >> class. >> >> Miles' T. Parker >> Principal >> Metascape, LLC >> "Extraordinary Tools for Extraordinary Science" >> mi...@me... >> http://metascapeabm.com >> >> On Sep 11, 2008, at 9:13 PM, Robert D Leclerc wrote: >> >>> Miles, >>> >>> No problem. I just posted a note to the RePast forum but it looks >>> like it'll >>> be too much effort. I was using repast because (a) the visualization >>> capabilities and (b) I thought it had a multithreaded scheduler. >>> However >>> since I only need (a) when I am not running in batch mode, and (b) >>> doesn't >>> do what I thought, I might try running kludging things together and >>> running >>> repast without scheduling the agent behaviour. I can still use the >>> DiffusionLayer and Grid classes so it's not all bad. >>> >>> Best >>> RDL >>> >>> -----Original Message----- >>> From: Miles Parker [mailto:mi...@me...] >>> Sent: Friday, September 12, 2008 12:01 AM >>> To: Robert D Leclerc >>> Subject: Re: [Repast-interest] Multithreading and ScheduledMethod >>> >>> >>> Hi Robert, >>> >>> I should have mentioned that I did that work in Ascape, sorry! The >>> Simphony architecture is pretty involved. But if you want to see the >>> general approach in Ascape, take a look at: >>> >>> >> > https://ascape.svn.sourceforge.net/svnroot/ascape/org.ascape.core/src/org/as >>> cape/model/engine/ >>> >>> You could start with: >>> >>> >> > https://ascape.svn.sourceforge.net/svnroot/ascape/org.ascape.core/src/org/as >>> cape/model/engine/ParallelManager.java >>> >>> and for the execute and update.. >>> >>> >> > https://ascape.svn.sourceforge.net/svnroot/ascape/org.ascape.core/src/org/as >>> cape/model/rule/ExecuteThenUpdate.java >>> >>> Its not as well javadoc'd as I'd like. >>> >>> Miles >>> >>> On Sep 11, 2008, at 8:31 PM, Robert D Leclerc wrote: >>> >>>> Miles >>>> >>>> Any chance you have some of the code for that? I really don't want >>>> to have to implement my code into one of the schedulers. There is a >>>> lot of abstraction, indirection, and call backs and it's not always >>>> easy to tell what is under the hood and how the work flow is >>>> executed. I think I'll post something to the list to see if someone >>>> is willing to give me a rundown of the Scheduler architecture and >>>> what pieces I would need to implement. >>>> >>>> >>>> Best, >>>> >>>> <image001.png> >>>> >>>> Robert D. Leclerc (PhD Fall 08) >>>> Yale University >>>> Osborn Memorial Laboratory >>>> New Haven, CT >>>> 06520 >>>> Email: rob...@ya... >>>> Hompage: http://pantheon.yale.edu/~rdl25/ >>>> >>>> -----Original Message----- >>>> From: Miles Parker [mailto:mil...@gm...] >>>> Sent: Thursday, September 11, 2008 9:35 PM >>>> To: Robert D Leclerc >>>> Cc: rep...@li... >>>> Subject: Re: [Repast-interest] Multithreading and ScheduledMethod >>>> >>>> >>>> Yes, I see what you mean. ;) I'd take that the same way you did >>>> -- I >>>> wasn't really thinking "group concurrent". But the schedule stuff >>>> is >>>> pretty deep so I think I'll leave any details on that to Nick. I >>>> note >>>> that there is a factory so it might not be that difficult to >>>> implement >>>> your own "agent concurrent" schedule. >>>> >>>> btw, I've played with an execute/update approach that supports what >>>> you suggest in a more specified way. The idea is that you have an >>>> "execute" (step) method who's contract is to only gather >>>> information, >>>> and an "update" method that can only write state based on prior >>>> actions. That worked well for diffusion type stuff, but once you >>>> get >>>> into movement, its more complicated of course.. One could support >>>> that >>>> with annotations as well.. I'll throw my usual saw in here and say >>>> that one would really like to be able to specify this orthogonally >>>> to >>>> the agent specification / classes themselves. >>>> >>>> On Sep 11, 2008, at 5:54 PM, Robert D Leclerc wrote: >>>> >>>>> Miles, >>>>> >>>>> I think I was mislead by the phrase: "A fully concurrent >>>> multithreaded >>>>> discrete event scheduler". The way I figured it, you should be >>>> able to >>>>> schedule "read/process" methods which can run in parallel, and >>>>> then >>>>> at some >>>>> meet up time you would sequentially call a separate set of stepX() >>>>> method >>>>> which need to perform "write" operations. Here it wouldn't be >>>>> necessary for >>>>> each agent to have a unique thread, but if you have say 5 threads >>>>> for each >>>>> CPU, you should be able to get a lot of work out of it. For >>>>> instance, if you >>>>> have several layers doing diffusion, then you could create an >>>>> agent >>>>> for each >>>>> and have them do the diffusion steps in parallel. >>>>> >>>>> Turns out I must have been doing something "funny" because I now >>>>> have the >>>>> second set of agent groups running concurrently with the first, >>>>> but >>>>> I have >>>>> the problem that any group blocks until the instance is finished >>>>> with the >>>>> method. In my model agents need to do some heavy calculations >>>>> and I >>>>> thought >>>>> I could use RePasts concurrency to make my life simpler. >>>>> >>>>> Seemingly it would be relatively straightforward to add a variable >>>>> "concurrentThreads" to the annotation to handle this? I've written >>>>> some >>>>> "compute thread" classes which I could probably drop in to a >>>>> customized >>>>> scheduling class, but I don't think I have the time to figure out >>>> the >>>>> Scheduler code to do it properly. >>>>> >>>>> Best, >>>>> RL >>>>> >>>>> -----Original Message----- >>>>> >>>>> This seems sensible to me -- all of the ABM environments I'm aware >>>> of >>>>> work this way, or should. ;) If this weren't the case, you'd lose >>>>> repeatability. Properly supporting parallel steps while retaining >>>>> fully determined behavior is a significant challenge. There was a >>>>> recent related thread a while ago, I think.. On the other hand if >>>> you >>>>> don't care about repeatability this is a totally reasonable thing >>>>> to >>>>> want to have as a (non-default) feature. I don't *think* this is >>>>> the >>>>> way the Simphony scheduler is supposed to work. Was there >>>> something in >>>>> the Simphony docs that made you think that? >>>>> >>>>> >>>>>> I am using RePast Simphony and I would like to execute the step() >>>>>> method for >>>>>> all instances of a given agent class in parallel to take >>>>>> advantage >>>>>> of my >>>>>> multi-core processor, but I seem to be having some trouble >>>>>> getting >>>>>> the >>>>>> scheduler to provide concurrency. >>>>>> >>>>>> To test concurrency I annotated the step() method of all my agent >>>>>> classes >>>>>> with: >>>>>> >>>>>> @ScheduledMethod(start = 0, duration = 1, interval = 1) >>>>>> >>>>>> Then for one of the classes I called Thread.sleep() in its step() >>>>>> function: >>>>>> >>>>>> @ScheduledMethod(start = 0, duration = 1, interval = 1) >>>>>> public void someStepMethod(){ >>>>>> System.out.println("Going to sleep: " + this.toString); >>>>>> try { >>>>>> Thread.sleep(3000); >>>>>> } catch (InterruptedException e) { >>>>>> e.printStackTrace(); >>>>>> } >>>>>> System.out.println("Waking up: " + this.toString); >>>>>> } >>>>>> >>>>>> >>>>>> When I ran this, I expected that other instances of this agent >>>> class >>>>>> would >>>>>> execute this method in parallel, and that the scheduler would >>>>>> wait >>>>>> until >>>>>> each agent had executed this method before moving on to the next >>>>>> tick. >>>>>> However this turned out not to be the case. Rather, calling >>>>>> Thread.sleep() >>>>>> blocked all other step() calls, both for instances of this class >>>>>> as >>>>>> well as >>>>>> instances of other classes calling their own step() functions. >>>>>> >>>>>> As I understood it, the Scheduler would execute these methods in >>>>>> their own >>>>>> threads then wait until all methods were complete before moving >>>>>> on >>>>>> to the >>>>>> next set of ticks. Is there something I am missing or not >>>> configuring >>>>>> properly? >>>>>> >>>>>> Thanks, >>>>>> RL >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>> > ------------------------------------------------------------------------- >>>>>> This SF.Net email is sponsored by the Moblin Your Move >>>>>> Developer's >>>>>> challenge >>>>>> Build the coolest Linux based applications with Moblin SDK & win >>>>>> great prizes >>>>>> Grand prize is a trip for two to an Open Source event anywhere in >>>>>> the world >>>>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >>>>>> _______________________________________________ >>>>>> Repast-interest mailing list >>>>>> Rep...@li... >>>>>> https://lists.sourceforge.net/lists/listinfo/repast-interest >>>>> >>>>> >>>>> >>>> > ------------------------------------------------------------------------- >>>>> This SF.Net email is sponsored by the Moblin Your Move Developer's >>>>> challenge >>>>> Build the coolest Linux based applications with Moblin SDK & win >>>>> great prizes >>>>> Grand prize is a trip for two to an Open Source event anywhere in >>>>> the world >>>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >>>>> _______________________________________________ >>>>> Repast-interest mailing list >>>>> Rep...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/repast-interest >>> >>> Miles T. Parker >>> Principal >>> Metascape, LLC >>> "Extraordinary Tools for Extraordinary Science" >>> mi...@me... >>> http://metascapeabm.com >>> >> < >> ParallelWorkService >> .java><ParrallelWorkServiceDemo.java><ProxiedMethod.java> > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win > great prizes > Grand prize is a trip for two to an Open Source event anywhere in > the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Repast-developer mailing list > Rep...@li... > https://lists.sourceforge.net/lists/listinfo/repast-developer |
|
From: North, M. <no...@an...> - 2008-09-15 12:30:59
|
Andy: First, thanks for your input! Second, not to be argumentative, but I never said that models with a large number of agents doing a small amount of work at every time step are fundamentally unparallelizable. I said such models are "likely," rather than certain, to fall into the category of poor scalability. This is especially true for nontrivial models with complex relationships between the agents (e.g., multiple dynamic networks and topologies) and the underlying platforms have problems such as substantial latency. The reduction approach you cite is a good example. In principle it seems straightforward. In practice, quite a bit of sophistication is often needed to get it to work. The level of sophistication rises as the agents within the model become increasingly intertwined. The agents don't really need to do much individual work for this to happen. They just need to potential to interact with many different agents in ways that are difficult to forecast in advance. In any case, I don't want to sound too pessimistic! There is quite a bit that can be done here. Furthermore, as you know, there are active research programs on these issues in several places, including here at Argonne. It is just that for real models this is a hard problem! Mike ________________________________ From: rep...@li... [mailto:rep...@li...] On Behalf Of Dr Andrew J Cleary Sent: Monday, September 15, 2008 1:27 PM To: rep...@li...; rep...@li... Subject: [Repast-interest] Fwd: [Repast-developer] MultithreadingandScheduledMethod Meant to send this to the whole list... ---------- Forwarded message ---------- From: Dr Andrew J Cleary <and...@gm...> Date: Mon, Sep 15, 2008 at 11:24 AM Subject: Re: [Repast-developer] [Repast-interest] Multithreading andScheduledMethod To: "North, Michael" <no...@an...> On Mon, Sep 15, 2008 at 10:46 AM, North, Michael <no...@an...> wrote: I'd like to add that the underlying issues go well beyond Repast, Ascape, or even Java. Fundamentally, it can be challenging to create efficient parallel programs and that even with the best tools only certain limited classes of problems are currently amenable to such implementations. A good resource on the design issues is Ian Foster's "Designing and Building Parallel Programs" web site: http://www-unix.mcs.anl.gov/dbpp/ If an algorithm has poor scalability as defined by Ian's "A Quantitative Basis for Design" chapter (http://tinyurl.com/54r3uc) then no toolkit whether it be in Java 6, Java 7, C/C++. High Performance Fortran or whatever can get it to run efficiently in parallel. Agent-based models that have a large number of agents doing a small amount of work at every time step are likely to fall into the category of poor scalability. Other classes of agent models which have agents doing large amounts of work per time step have at least the potential for, although not the guarantee of, better scalability.. I think you are reading a bit too much into the above references: a large number of agents doing a small amount of work at every time step isn't *fundamentally* unparallelizable, it just may take a little more work than the easier case of independent heavy-weight agents. There's a difference between algorithms/computations that *cannot* be parallelized, and those where it's not *easy* to parallelize but can still be done. In this case, there's kind of a reduction that makes this work: define a conceptual "heavyweight agent" whose job it is to run a batch of the small agents. Now you've reduced the harder problem to the easier one, though you have to do some programming work to do the transformation. The case that is fundamentally undoable is a small number of agents with a small amount of work, or any model in which you have tight causality that prevents independent events from being processed... The "time step" is often overlooked in its importance for parallelization - it's been such a fundamental part of ABM frameworks since the beginning that we take it for granted - but there is no rule that says that all models should be expressible in timesteps. Fortunately, timesteps are akin to a parallelization annotation: "everything being done in the same timestep is independent of each other". It's just not going to provide much parallelization unless there are a *lot* of things going in at the same timestep, either a lot of "agents" or a lot of computation per agent (or both). Andy, from the sidelines... |
198 messages has been excluded from this view by a project administrator.
