Friam

Ruby on Rails

Classic

List

Threaded

27 messages Options

Russell Standish

Ruby on Rails

Neither of these approaches solve the problem I was posing. The Flash
solution (IIUC) is basically posting a movie of a simulation - it
doesn't allow the user to muck around with parameters. I can already
do this, as there are recipes for exporting MPEG or AVI files from
EcoLab (as there is from RePast too, its not a terribly difficult concept).

Nor do I want to host the C++ objects on a server. If I wanted to do
this, I could simply expose EcoLab objects to Java, and then provide a
Java applet that talks back to the EcoLab server. Its doable, although
not yet done 'coz its not what I want to do.

Probabably what would solve it is a C++ -> JVM compiler. Do such
things exist? Could such things be developed from tools like GCC? The
closest thing to what I want is .NET, but .NET doesn't yet do it.

On Tue, Nov 22, 2005 at 10:45:46AM -0700, Giles Bowkett wrote:

> > Of course what would be nice is to automatically generate web applet
> > demos from your model, but at present I can see no technology capable
> > of doing this that is not fundamentally at odds with running your
> > model at high performance. Sigh...dream on.
>
> It might be possible to do some kind of "glue language" thing with
> Python and Blender. I think Steve's already suggested this actually.
> Blender is a 3d package written and entirely scriptable in Python.
> Essentially a very powerful visualization library with a strong GUI.
> You can link up Python with C++ objects, and I believe that Python
> libraries for the Flash format also exist. C++ objects which run
> within EcoLab and are available to a Tcl interpreter must have a
> reasonably predictable structure, and if you can make them available
> to Tcl, you can probably make them available to Python too. From
> Python to Blender, and from Blender to Flash, and then you have an
> output format anybody can use.
>
> However, there are lot of steps involved, and this doesn't include any
> method to preserve the interactivity, which is probably essential to
> the usefulness of any simulation. If you were like super hardcore
> gung-ho about it, you could probably do the whole thing with Ajax and
> Flash Remoting, hosting the simulation code on a server in C or Java
> and just sending the output to the browser. Flash Remoting is
> basically just XML-RPC with some added proprietary obfuscation bits. I
> think it's been reverse-engineered in enough detail to be useful.
> Python libraries for it already exist, so you could,
> **theoretically**, set up an Ajax/Flash front end to a low-level
> simulation package.
>
> The architecture is actually the canonical web app architecture,
> model/view/controller. Most web apps don't have agent-based
> simulations for the models or Blender-->Flash visualization
> translators for the views, but the structure is the same.
>
> However, it would probably be a nontrivial system.
>
> On 11/21/05, Russell Standish <r.standish at unsw.edu.au> wrote:
> > Good point, and partly this is how EcoLab eases the programming
> > pain. What you do is code a C++ object that implements just your
> > model, and an appropriate set of primitive operations acting on
> > it. EcoLab ensures that this object, and its methods is available
> > within a TCL interpreter. Prototyping then is very quick - TCL
> > scripting is enormously productive to the initiated, and even
> > bog-standard modeling tasks are easy for the novitiate.
> >
> > Once your model tinkering phase is over, you simply write a TCL script
> > that executes the model in a batch environment. Practical experience
> > indicates that the extra overhead of running a TCL interpreter is
> > negligible compared model executaion time. Apart from running a
> > profiler over your code, it really is production ready.
> >
> > Of course this is not to say that TCL is the best tool - presumably
> > Python, or Ruby or whatever have their advantages too - but its what
> > has been deployed with EcoLab for historical reasons. I am playing
> > around with the concept of using RePast (or MASON or whatever) as an
> > interactive framework for exploration of EcoLab coded models - this
> > would save me the effort of creating and maintaining GUI probes and
> > instruments. I would still keep TCL scripting for initialisation and
> > scheduling though, as this seems to me to be vastly superior than
> > RePast's batch environment...
> >
> > Of course what would be nice is to automatically generate web applet
> > demos from your model, but at present I can see no technology capable
> > of doing this that is not fundamentally at odds with running your
> > model at high performance. Sigh...dream on.
> >
> > Cheers
> >
> > On Mon, Nov 21, 2005 at 06:18:19PM -0500, Martin C. Martin wrote:
> > > I agree with the simulation speed idea. Simulations (and other
> > > scientific computing) are different than, say, word processors in that
> > > way. But there are often only a few bottlenecks, and they're often not
> > > where you think they will be. Donald Knuth has a saying, "premature
> > > optimization is the root of all evil." Once you code it up and use a
> > > profiler to identify the bottlenecks, you can recode those in something
> > > fast like C/Java. It seems overboard to me to pick a language that
> > > forces you to specify everything minutely (and largely efficiently).
> > >
> > > - Martin
> > >
> > > Russell Standish wrote:
> > >
> > > >Indeed - speed of prototyping is a very important issue. But so is
> > > >simulation speed. I have so often seen new effects come out of a model
> > > >when simulations are scaled up to longer runs, or more agents. Quite
> > > >often ones understanding obtained through the prototyping phase is
> > > >turned around during production runs.
> > > >
> > > >EcoLab does make it substantially easier to implement scalable C++
> > > >models (my guesstimate is perhaps by a factor of 4-5 over raw C++). I
> > > >personally think it is easier to use than Swarm, but this might be my
> > > >bias showing through. :) It is not as simple to use as say Matlab, or
> > > >presumably Netlogo (which I haven't used), which are perhaps a factor
> > > >of 2-3 easier again.
> > > >
> > > >However one does it, though I do think it a mistake to skip the
> > > >production run step altogether. Too often I have seen methodologically
> > > >unsound results reported due to a prototype not being reimplemented in
> > > >a high performance environment, and so being limited in its
> > > >computational testing.
> > > >
> > > >Cheers
> > > >
> > > >On Mon, Nov 21, 2005 at 09:09:12AM -0700, Owen Densmore wrote:
> > > >
> > > >
> > > >>Oh, and I left out the most important factor: dueling models!
> > > >>
> > > >>It's so fast to get netlogo models running, we almost always do a
> > > >>"silly" level-0 model that lets us get the algorithms right and then
> > > >>"the real" model .. and with one recent project, two "real models" ..
> > > >>one at a low resolution but with a large scope (zozobra with all of
> > > >>Ft Marcy park) and one at high resolution (zozobra with just the
> > > >>baseball diamond).
> > > >>
> > > >>This two-level approach is often very useful with client interaction
> > > >>as well .. we can show what we're doing and very quickly respond to
> > > >>feedback. Indeed, with the recent Stadium model we did, we weren't
> > > >>really sure which the client would go for until near the end of the
> > > >>project.
> > > >>
> > > >> -- Owen
> > > >>
> > > >>Owen Densmore
> > > >>http://backspaces.net - http://redfish.com - http://friam.org
> > > >>
> > > >>
> > > >>On Nov 21, 2005, at 8:47 AM, Owen Densmore wrote:
> > > >>
> > > >>
> > > >>
> > > >>>A surprising amount of our modeling is done with netlogo. RePast
> > > >>>used to be used quite a bit but we found that there was nothing we
> > > >>>could not do in netlogo, so due to RePast being more difficult to
> > > >>>program, we've settled happily on netlogo. It has the happy side
> > > >>>effect that more of the folks involved in the simulation can easily
> > > >>>read the code as well, and deploys simply in web pages.
> > > >>>
> > > >>>That said, I should mention that we do quite a bit outside of the
> > > >>>model itself. Stephen uses the model data in various visualization
> > > >>>packages to make the data far more understandable by clients. We
> > > >>>also find ourselves using statistics packages like R to analyze
> > > >>>parameter scans done in netlogo. This lets us output simple text
> > > >>>formatted data from netlogo and pass it on to more sophisticated
> > > >>>systems.
> > > >>>
> > > >>>Thus our view of simulation and modeling has become one of several
> > > >>>systems working in concert rather than a single package like RePast
> > > >>>or netlogo or the like.
> > > >>>
> > > >>> -- Owen
> > > >>>
> > > >>>Owen Densmore
> > > >>>http://backspaces.net - http://redfish.com - http://friam.org
> > > >>>
> > > >>>
> > > >>>On Nov 20, 2005, at 6:46 PM, Martin C. Martin wrote:
> > > >>>
> > > >>>
> > > >>>
> > > >>>>Russell Standish wrote:
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>>What's it for? The website indicates its for website development,
> > > >>>>>but
> > > >>>>>unless that's what you do for a living, is it of interest? For
> > > >>>>>instance is it useful for doing simulations?
> > > >>>>>
> > > >>>>>Cheers
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>Well, Ruby probably is.
> > > >>>>
> > > >>>>Out of curiosity, how many people here do simulations in a high level
> > > >>>>language (e.g. Java or C++) vs. a very high level language (like
> > > >>>>Ruby,
> > > >>>>Python or perl)?
> > > >>>>
> > > >>>>- Martin
> > > >>>>
> > > >>>>
> > > >>>>============================================================
> > > >>>>FRIAM Applied Complexity Group listserv
> > > >>>>Meets Fridays 9a-11:30 at Mission Cafe
> > > >>>>Wed Lecture schedule, archives, unsubscribe, maps, etc. at http://
> > > >>>>www.friam.org
> > > >>>>
> > > >>>>
> > > >>>============================================================
> > > >>>FRIAM Applied Complexity Group listserv
> > > >>>Meets Fridays 9a-11:30 at Mission Cafe
> > > >>>Wed Lecture schedule, archives, unsubscribe, maps, etc. at http://
> > > >>>www.friam.org
> > > >>>
> > > >>>
> > > >>============================================================
> > > >>FRIAM Applied Complexity Group listserv
> > > >>Meets Fridays 9a-11:30 at Mission Cafe
> > > >>Wed Lecture schedule, archives, unsubscribe, maps, etc. at
> > > >>http://www.friam.org
> > > >>
> > > >>
> > > >
> > > >
> > > >
> >
> > > ============================================================
> > > FRIAM Applied Complexity Group listserv
> > > Meets Fridays 9a-11:30 at Mission Cafe
> > > Wed Lecture schedule, archives, unsubscribe, maps, etc. at http://www.friam.org
> >
> > --
> > *PS: A number of people ask me about the attachment to my email, which
> > is of type "application/pgp-signature". Don't worry, it is not a
> > virus. It is an electronic signature, that may be used to verify this
> > email came from me if you have PGP or GPG installed. Otherwise, you
> > may safely ignore this attachment.
> >
> > ----------------------------------------------------------------------------
> > A/Prof Russell Standish Phone 8308 3119 (mobile)
> > Mathematics 0425 253119 (")
> > UNSW SYDNEY 2052 R.Standish at unsw.edu.au
> > Australia http://parallel.hpc.unsw.edu.au/rks
> > International prefix +612, Interstate prefix 02
> > ----------------------------------------------------------------------------
> >
> > ============================================================
> > FRIAM Applied Complexity Group listserv
> > Meets Fridays 9a-11:30 at Mission Cafe
> > Wed Lecture schedule, archives, unsubscribe, maps, etc. at http://www.friam.org
> >
>
>
> --
> Giles Bowkett = Giles Goat Boy
> http://www.gilesgoatboy.org/
>
> ============================================================
> FRIAM Applied Complexity Group listserv
> Meets Fridays 9a-11:30 at Mission Cafe
> Wed Lecture schedule, archives, unsubscribe, maps, etc. at http://www.friam.org

--
*PS: A number of people ask me about the attachment to my email, which
is of type "application/pgp-signature". Don't worry, it is not a
virus. It is an electronic signature, that may be used to verify this
email came from me if you have PGP or GPG installed. Otherwise, you
may safely ignore this attachment.

----------------------------------------------------------------------------
A/Prof Russell Standish Phone 8308 3119 (mobile)
Mathematics 0425 253119 (")
UNSW SYDNEY 2052 R.Standish at unsw.edu.au
Australia http://parallel.hpc.unsw.edu.au/rks
International prefix +612, Interstate prefix 02
----------------------------------------------------------------------------

Giles Bowkett

Ruby on Rails

If what you want is an applet compiled from C++, I don't think that
exists. Exposing EcoLab to Java sounds like your best bet. I know
virtually nothing about compilers, but I'd guess that compiling a
not-garbage-collected language to a garbage-collected one could be a
can of worms.

Sorry, I was kind of just thinking out loud.

On 11/22/05, Russell Standish <r.standish at unsw.edu.au> wrote:

> Neither of these approaches solve the problem I was posing. The Flash
> solution (IIUC) is basically posting a movie of a simulation - it
> doesn't allow the user to muck around with parameters. I can already
> do this, as there are recipes for exporting MPEG or AVI files from
> EcoLab (as there is from RePast too, its not a terribly difficult concept).
>
> Nor do I want to host the C++ objects on a server. If I wanted to do
> this, I could simply expose EcoLab objects to Java, and then provide a
> Java applet that talks back to the EcoLab server. Its doable, although
> not yet done 'coz its not what I want to do.
>
> Probabably what would solve it is a C++ -> JVM compiler. Do such
> things exist? Could such things be developed from tools like GCC? The
> closest thing to what I want is .NET, but .NET doesn't yet do it.
>
> On Tue, Nov 22, 2005 at 10:45:46AM -0700, Giles Bowkett wrote:
> > > Of course what would be nice is to automatically generate web applet
> > > demos from your model, but at present I can see no technology capable
> > > of doing this that is not fundamentally at odds with running your
> > > model at high performance. Sigh...dream on.
> >
> > It might be possible to do some kind of "glue language" thing with
> > Python and Blender. I think Steve's already suggested this actually.
> > Blender is a 3d package written and entirely scriptable in Python.
> > Essentially a very powerful visualization library with a strong GUI.
> > You can link up Python with C++ objects, and I believe that Python
> > libraries for the Flash format also exist. C++ objects which run
> > within EcoLab and are available to a Tcl interpreter must have a
> > reasonably predictable structure, and if you can make them available
> > to Tcl, you can probably make them available to Python too. From
> > Python to Blender, and from Blender to Flash, and then you have an
> > output format anybody can use.
> >
> > However, there are lot of steps involved, and this doesn't include any
> > method to preserve the interactivity, which is probably essential to
> > the usefulness of any simulation. If you were like super hardcore
> > gung-ho about it, you could probably do the whole thing with Ajax and
> > Flash Remoting, hosting the simulation code on a server in C or Java
> > and just sending the output to the browser. Flash Remoting is
> > basically just XML-RPC with some added proprietary obfuscation bits. I
> > think it's been reverse-engineered in enough detail to be useful.
> > Python libraries for it already exist, so you could,
> > **theoretically**, set up an Ajax/Flash front end to a low-level
> > simulation package.
> >
> > The architecture is actually the canonical web app architecture,
> > model/view/controller. Most web apps don't have agent-based
> > simulations for the models or Blender-->Flash visualization
> > translators for the views, but the structure is the same.
> >
> > However, it would probably be a nontrivial system.
> >
> > On 11/21/05, Russell Standish <r.standish at unsw.edu.au> wrote:
> > > Good point, and partly this is how EcoLab eases the programming
> > > pain. What you do is code a C++ object that implements just your
> > > model, and an appropriate set of primitive operations acting on
> > > it. EcoLab ensures that this object, and its methods is available
> > > within a TCL interpreter. Prototyping then is very quick - TCL
> > > scripting is enormously productive to the initiated, and even
> > > bog-standard modeling tasks are easy for the novitiate.
> > >
> > > Once your model tinkering phase is over, you simply write a TCL script
> > > that executes the model in a batch environment. Practical experience
> > > indicates that the extra overhead of running a TCL interpreter is
> > > negligible compared model executaion time. Apart from running a
> > > profiler over your code, it really is production ready.
> > >
> > > Of course this is not to say that TCL is the best tool - presumably
> > > Python, or Ruby or whatever have their advantages too - but its what
> > > has been deployed with EcoLab for historical reasons. I am playing
> > > around with the concept of using RePast (or MASON or whatever) as an
> > > interactive framework for exploration of EcoLab coded models - this
> > > would save me the effort of creating and maintaining GUI probes and
> > > instruments. I would still keep TCL scripting for initialisation and
> > > scheduling though, as this seems to me to be vastly superior than
> > > RePast's batch environment...
> > >
> > > Of course what would be nice is to automatically generate web applet
> > > demos from your model, but at present I can see no technology capable
> > > of doing this that is not fundamentally at odds with running your
> > > model at high performance. Sigh...dream on.
> > >
> > > Cheers
> > >
> > > On Mon, Nov 21, 2005 at 06:18:19PM -0500, Martin C. Martin wrote:
> > > > I agree with the simulation speed idea. Simulations (and other
> > > > scientific computing) are different than, say, word processors in that
> > > > way. But there are often only a few bottlenecks, and they're often not
> > > > where you think they will be. Donald Knuth has a saying, "premature
> > > > optimization is the root of all evil." Once you code it up and use a
> > > > profiler to identify the bottlenecks, you can recode those in something
> > > > fast like C/Java. It seems overboard to me to pick a language that
> > > > forces you to specify everything minutely (and largely efficiently).
> > > >
> > > > - Martin
> > > >
> > > > Russell Standish wrote:
> > > >
> > > > >Indeed - speed of prototyping is a very important issue. But so is
> > > > >simulation speed. I have so often seen new effects come out of a model
> > > > >when simulations are scaled up to longer runs, or more agents. Quite
> > > > >often ones understanding obtained through the prototyping phase is
> > > > >turned around during production runs.
> > > > >
> > > > >EcoLab does make it substantially easier to implement scalable C++
> > > > >models (my guesstimate is perhaps by a factor of 4-5 over raw C++). I
> > > > >personally think it is easier to use than Swarm, but this might be my
> > > > >bias showing through. :) It is not as simple to use as say Matlab, or
> > > > >presumably Netlogo (which I haven't used), which are perhaps a factor
> > > > >of 2-3 easier again.
> > > > >
> > > > >However one does it, though I do think it a mistake to skip the
> > > > >production run step altogether. Too often I have seen methodologically
> > > > >unsound results reported due to a prototype not being reimplemented in
> > > > >a high performance environment, and so being limited in its
> > > > >computational testing.
> > > > >
> > > > >Cheers
> > > > >
> > > > >On Mon, Nov 21, 2005 at 09:09:12AM -0700, Owen Densmore wrote:
> > > > >
> > > > >
> > > > >>Oh, and I left out the most important factor: dueling models!
> > > > >>
> > > > >>It's so fast to get netlogo models running, we almost always do a
> > > > >>"silly" level-0 model that lets us get the algorithms right and then
> > > > >>"the real" model .. and with one recent project, two "real models" ..
> > > > >>one at a low resolution but with a large scope (zozobra with all of
> > > > >>Ft Marcy park) and one at high resolution (zozobra with just the
> > > > >>baseball diamond).
> > > > >>
> > > > >>This two-level approach is often very useful with client interaction
> > > > >>as well .. we can show what we're doing and very quickly respond to
> > > > >>feedback. Indeed, with the recent Stadium model we did, we weren't
> > > > >>really sure which the client would go for until near the end of the
> > > > >>project.
> > > > >>
> > > > >> -- Owen
> > > > >>
> > > > >>Owen Densmore
> > > > >>http://backspaces.net - http://redfish.com - http://friam.org
> > > > >>
> > > > >>
> > > > >>On Nov 21, 2005, at 8:47 AM, Owen Densmore wrote:
> > > > >>
> > > > >>
> > > > >>
> > > > >>>A surprising amount of our modeling is done with netlogo. RePast
> > > > >>>used to be used quite a bit but we found that there was nothing we
> > > > >>>could not do in netlogo, so due to RePast being more difficult to
> > > > >>>program, we've settled happily on netlogo. It has the happy side
> > > > >>>effect that more of the folks involved in the simulation can easily
> > > > >>>read the code as well, and deploys simply in web pages.
> > > > >>>
> > > > >>>That said, I should mention that we do quite a bit outside of the
> > > > >>>model itself. Stephen uses the model data in various visualization
> > > > >>>packages to make the data far more understandable by clients. We
> > > > >>>also find ourselves using statistics packages like R to analyze
> > > > >>>parameter scans done in netlogo. This lets us output simple text
> > > > >>>formatted data from netlogo and pass it on to more sophisticated
> > > > >>>systems.
> > > > >>>
> > > > >>>Thus our view of simulation and modeling has become one of several
> > > > >>>systems working in concert rather than a single package like RePast
> > > > >>>or netlogo or the like.
> > > > >>>
> > > > >>> -- Owen
> > > > >>>
> > > > >>>Owen Densmore
> > > > >>>http://backspaces.net - http://redfish.com - http://friam.org
> > > > >>>
> > > > >>>
> > > > >>>On Nov 20, 2005, at 6:46 PM, Martin C. Martin wrote:
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>>Russell Standish wrote:
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>>>What's it for? The website indicates its for website development,
> > > > >>>>>but
> > > > >>>>>unless that's what you do for a living, is it of interest? For
> > > > >>>>>instance is it useful for doing simulations?
> > > > >>>>>
> > > > >>>>>Cheers
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>
> > > > >>>>Well, Ruby probably is.
> > > > >>>>
> > > > >>>>Out of curiosity, how many people here do simulations in a high level
> > > > >>>>language (e.g. Java or C++) vs. a very high level language (like
> > > > >>>>Ruby,
> > > > >>>>Python or perl)?
> > > > >>>>
> > > > >>>>- Martin
> > > > >>>>
> > > > >>>>
> > > > >>>>============================================================
> > > > >>>>FRIAM Applied Complexity Group listserv
> > > > >>>>Meets Fridays 9a-11:30 at Mission Cafe
> > > > >>>>Wed Lecture schedule, archives, unsubscribe, maps, etc. at http://
> > > > >>>>www.friam.org
> > > > >>>>
> > > > >>>>
> > > > >>>============================================================
> > > > >>>FRIAM Applied Complexity Group listserv
> > > > >>>Meets Fridays 9a-11:30 at Mission Cafe
> > > > >>>Wed Lecture schedule, archives, unsubscribe, maps, etc. at http://
> > > > >>>www.friam.org
> > > > >>>
> > > > >>>
> > > > >>============================================================
> > > > >>FRIAM Applied Complexity Group listserv
> > > > >>Meets Fridays 9a-11:30 at Mission Cafe
> > > > >>Wed Lecture schedule, archives, unsubscribe, maps, etc. at
> > > > >>http://www.friam.org
> > > > >>
> > > > >>
> > > > >
> > > > >
> > > > >
> > >
> > > > ============================================================
> > > > FRIAM Applied Complexity Group listserv
> > > > Meets Fridays 9a-11:30 at Mission Cafe
> > > > Wed Lecture schedule, archives, unsubscribe, maps, etc. at http://www.friam.org
> > >
> > > --
> > > *PS: A number of people ask me about the attachment to my email, which
> > > is of type "application/pgp-signature". Don't worry, it is not a
> > > virus. It is an electronic signature, that may be used to verify this
> > > email came from me if you have PGP or GPG installed. Otherwise, you
> > > may safely ignore this attachment.
> > >
> > > ----------------------------------------------------------------------------
> > > A/Prof Russell Standish Phone 8308 3119 (mobile)
> > > Mathematics 0425 253119 (")
> > > UNSW SYDNEY 2052 R.Standish at unsw.edu.au
> > > Australia http://parallel.hpc.unsw.edu.au/rks
> > > International prefix +612, Interstate prefix 02
> > > ----------------------------------------------------------------------------
> > >
> > > ============================================================
> > > FRIAM Applied Complexity Group listserv
> > > Meets Fridays 9a-11:30 at Mission Cafe
> > > Wed Lecture schedule, archives, unsubscribe, maps, etc. at http://www.friam.org
> > >
> >
> >
> > --
> > Giles Bowkett = Giles Goat Boy
> > http://www.gilesgoatboy.org/
> >
> > ============================================================
> > FRIAM Applied Complexity Group listserv
> > Meets Fridays 9a-11:30 at Mission Cafe
> > Wed Lecture schedule, archives, unsubscribe, maps, etc. at http://www.friam.org
>
> --
> *PS: A number of people ask me about the attachment to my email, which
> is of type "application/pgp-signature". Don't worry, it is not a
> virus. It is an electronic signature, that may be used to verify this
> email came from me if you have PGP or GPG installed. Otherwise, you
> may safely ignore this attachment.
>
> ----------------------------------------------------------------------------
> A/Prof Russell Standish Phone 8308 3119 (mobile)
> Mathematics 0425 253119 (")
> UNSW SYDNEY 2052 R.Standish at unsw.edu.au
> Australia http://parallel.hpc.unsw.edu.au/rks
> International prefix +612, Interstate prefix 02
> ----------------------------------------------------------------------------
>
> ============================================================
> FRIAM Applied Complexity Group listserv
> Meets Fridays 9a-11:30 at Mission Cafe
> Wed Lecture schedule, archives, unsubscribe, maps, etc. at http://www.friam.org
>

--
Giles Bowkett = Giles Goat Boy
http://www.gilesgoatboy.org/

Owen Densmore

Modeling Systems

Administrator

In reply to this post by Russell Standish

Hi Russell. Interesting system, EcoLab .. and I'm going to read the
great articles and papers your home page points to. Of particular
interest were those relating to HPC.

This teases out an interesting challenge we've had with our focus on
NetLogo:
"What can't be done with NetLogo that can be done by other systems"

Here are some talking points:

- Good statistics: Not a problems, just output the data and use in
Matlab, Octave, R, J, Mathematica and so on. We sorta prefer this
multi-tool approach anyway.

- Better plotting: Ditto .. export the data and let other programs
like the above do the work. Stephen even has built some movies that
show graphs evolving nicely with the associated models using
sophisticated video tools.

- Hex Grids: Yes, this is a fairly major problem in NetLogo, although
there are some stunts such as single pixel grids, using a "turtle"
hex layer, or running on a graph rather than a grid. But definitely
an issue.

- HPC: Yes, this is also a problem. We've been discussing in on the
NetLogo list a bit. Interestingly enough, for most of our problems,
simply using several computers in a grid/cluster or on a
multiprocessor system works fine because the large computing overhead
comes for us in the parameter scanning phase, which works fine with
NetLogo and any HPC environment.

- 3D, Game Systems, "high resolution simulation". This is a maybe.
NetLogo does have two levels of 3D support, both of which are quite
useful. But for true "realistic" modeling we've exported agent
positions into scene systems like Maya.

Anyway, we have not found RePast or others to be enough better to
push us off the NetLogo band wagon!

-- Owen

Owen Densmore
http://backspaces.net - http://redfish.com - http://friam.org

On Nov 21, 2005, at 4:05 PM, Russell Standish wrote:

> Indeed - speed of prototyping is a very important issue. But so is
> simulation speed. I have so often seen new effects come out of a model
> when simulations are scaled up to longer runs, or more agents. Quite
> often ones understanding obtained through the prototyping phase is
> turned around during production runs.
>
> EcoLab does make it substantially easier to implement scalable C++
> models (my guesstimate is perhaps by a factor of 4-5 over raw C++). I
> personally think it is easier to use than Swarm, but this might be my
> bias showing through. :) It is not as simple to use as say Matlab, or
> presumably Netlogo (which I haven't used), which are perhaps a factor
> of 2-3 easier again.
>
> However one does it, though I do think it a mistake to skip the
> production run step altogether. Too often I have seen methodologically
> unsound results reported due to a prototype not being reimplemented in
> a high performance environment, and so being limited in its
> computational testing.
>
> Cheers
>
> On Mon, Nov 21, 2005 at 09:09:12AM -0700, Owen Densmore wrote:
>> Oh, and I left out the most important factor: dueling models!
>>
>> It's so fast to get netlogo models running, we almost always do a
>> "silly" level-0 model that lets us get the algorithms right and then
>> "the real" model .. and with one recent project, two "real models" ..
>> one at a low resolution but with a large scope (zozobra with all of
>> Ft Marcy park) and one at high resolution (zozobra with just the
>> baseball diamond).
>>
>> This two-level approach is often very useful with client interaction
>> as well .. we can show what we're doing and very quickly respond to
>> feedback. Indeed, with the recent Stadium model we did, we weren't
>> really sure which the client would go for until near the end of the
>> project.
>>
>> -- Owen
>>
>> Owen Densmore
>> http://backspaces.net - http://redfish.com - http://friam.org
>>
>>
>> On Nov 21, 2005, at 8:47 AM, Owen Densmore wrote:
>>
>>> A surprising amount of our modeling is done with netlogo. RePast
>>> used to be used quite a bit but we found that there was nothing we
>>> could not do in netlogo, so due to RePast being more difficult to
>>> program, we've settled happily on netlogo. It has the happy side
>>> effect that more of the folks involved in the simulation can easily
>>> read the code as well, and deploys simply in web pages.
>>>
>>> That said, I should mention that we do quite a bit outside of the
>>> model itself. Stephen uses the model data in various visualization
>>> packages to make the data far more understandable by clients. We
>>> also find ourselves using statistics packages like R to analyze
>>> parameter scans done in netlogo. This lets us output simple text
>>> formatted data from netlogo and pass it on to more sophisticated
>>> systems.
>>>
>>> Thus our view of simulation and modeling has become one of several
>>> systems working in concert rather than a single package like RePast
>>> or netlogo or the like.
>>>
>>> -- Owen
>>>
>>> Owen Densmore
>>> http://backspaces.net - http://redfish.com - http://friam.org
>>>
>>>
>>> On Nov 20, 2005, at 6:46 PM, Martin C. Martin wrote:
>>>
>>>>
>>>>
>>>> Russell Standish wrote:
>>>>
>>>>> What's it for? The website indicates its for website development,
>>>>> but
>>>>> unless that's what you do for a living, is it of interest? For
>>>>> instance is it useful for doing simulations?
>>>>>
>>>>> Cheers
>>>>>
>>>>>
>>>>
>>>> Well, Ruby probably is.
>>>>
>>>> Out of curiosity, how many people here do simulations in a high
>>>> level
>>>> language (e.g. Java or C++) vs. a very high level language (like
>>>> Ruby,
>>>> Python or perl)?
>>>>
>>>> - Martin
>>>>
>>>>
>>>> ============================================================
>>>> FRIAM Applied Complexity Group listserv
>>>> Meets Fridays 9a-11:30 at Mission Cafe
>>>> Wed Lecture schedule, archives, unsubscribe, maps, etc. at http://
>>>> www.friam.org
>>>
>>>
>>> ============================================================
>>> FRIAM Applied Complexity Group listserv
>>> Meets Fridays 9a-11:30 at Mission Cafe
>>> Wed Lecture schedule, archives, unsubscribe, maps, etc. at http://
>>> www.friam.org
>>
>>
>> ============================================================
>> FRIAM Applied Complexity Group listserv
>> Meets Fridays 9a-11:30 at Mission Cafe
>> Wed Lecture schedule, archives, unsubscribe, maps, etc. at http://
>> www.friam.org
>
> --
> *PS: A number of people ask me about the attachment to my email, which
> is of type "application/pgp-signature". Don't worry, it is not a
> virus. It is an electronic signature, that may be used to verify this
> email came from me if you have PGP or GPG installed. Otherwise, you
> may safely ignore this attachment.
>
> ----------------------------------------------------------------------
> ------
> A/Prof Russell Standish Phone 8308 3119 (mobile)
> Mathematics 0425 253119 (")
> UNSW SYDNEY 2052 R.Standish at unsw.edu.au
> Australia http://
> parallel.hpc.unsw.edu.au/rks
> International prefix +612, Interstate prefix 02
> ----------------------------------------------------------------------
> ------
>
> ============================================================
> FRIAM Applied Complexity Group listserv
> Meets Fridays 9a-11:30 at Mission Cafe
> Wed Lecture schedule, archives, unsubscribe, maps, etc. at http://
> www.friam.org

Russell Standish

Modeling Systems

On Tue, Nov 22, 2005 at 04:58:21PM -0700, Owen Densmore wrote:

> Hi Russell. Interesting system, EcoLab .. and I'm going to read the
> great articles and papers your home page points to. Of particular
> interest were those relating to HPC.
>
> This teases out an interesting challenge we've had with our focus on
> NetLogo:
> "What can't be done with NetLogo that can be done by other systems"
>
> Here are some talking points:
>
> - Good statistics: Not a problems, just output the data and use in
> Matlab, Octave, R, J, Mathematica and so on. We sorta prefer this
> multi-tool approach anyway.
>
> - Better plotting: Ditto .. export the data and let other programs
> like the above do the work. Stephen even has built some movies that
> show graphs evolving nicely with the associated models using
> sophisticated video tools.

Absolutely true, although during model exploration mode it is useful
to have crude analysis tools at hand that can be dynamically fed by
the model as it runs.

>
> - Hex Grids: Yes, this is a fairly major problem in NetLogo, although
> there are some stunts such as single pixel grids, using a "turtle"
> hex layer, or running on a graph rather than a grid. But definitely
> an issue.
>

EcoLab's graphcode library provides the basis for setting up grids (of
arbitrary dimension and topology). What it lacks at present is a
library of templates to make life easier.

> - HPC: Yes, this is also a problem. We've been discussing in on the
> NetLogo list a bit. Interestingly enough, for most of our problems,
> simply using several computers in a grid/cluster or on a
> multiprocessor system works fine because the large computing overhead
> comes for us in the parameter scanning phase, which works fine with
> NetLogo and any HPC environment.
>

Yes - most people use HPC systems this way, and its perfectly
fine. However something like EcoLab allows one to scale models to the
very large, not just the very many. This opens up new simulation
possibilities, which surely is a good thing!

> - 3D, Game Systems, "high resolution simulation". This is a maybe.
> NetLogo does have two levels of 3D support, both of which are quite
> useful. But for true "realistic" modeling we've exported agent
> positions into scene systems like Maya.
>

Support for arbitrary dimensional space systems is there in EcoLab -
anything that can be represented as a graph or network topology is
possible, which let's face it is any discrete space.

Continuous spaces are also possible - in which case, the discrete
network topology is used to identify neighbourhood relationships. AKA
"particle in cell" methods.

Rendering to graphics is better done with dedicated tools like Maya or
Blender as a batch postprocessing step though. I've contemplated
integrating VTK to EcoLab, but the programming style is too different
for it to be an easy task I suspect.

> Anyway, we have not found RePast or others to be enough better to
> push us off the NetLogo band wagon!
>

I guess I've felt the same way - none of these other systems have been
good enough to push me off a C++-based system. I'm only tempted to add
in something like RePast support to get out of the GUI support business...

> -- Owen
>
> Owen Densmore
> http://backspaces.net - http://redfish.com - http://friam.org
>
>
> On Nov 21, 2005, at 4:05 PM, Russell Standish wrote:
>
> > Indeed - speed of prototyping is a very important issue. But so is
> > simulation speed. I have so often seen new effects come out of a model
> > when simulations are scaled up to longer runs, or more agents. Quite
> > often ones understanding obtained through the prototyping phase is
> > turned around during production runs.
> >
> > EcoLab does make it substantially easier to implement scalable C++
> > models (my guesstimate is perhaps by a factor of 4-5 over raw C++). I
> > personally think it is easier to use than Swarm, but this might be my
> > bias showing through. :) It is not as simple to use as say Matlab, or
> > presumably Netlogo (which I haven't used), which are perhaps a factor
> > of 2-3 easier again.
> >
> > However one does it, though I do think it a mistake to skip the
> > production run step altogether. Too often I have seen methodologically
> > unsound results reported due to a prototype not being reimplemented in
> > a high performance environment, and so being limited in its
> > computational testing.
> >
> > Cheers
> >
> > On Mon, Nov 21, 2005 at 09:09:12AM -0700, Owen Densmore wrote:
> >> Oh, and I left out the most important factor: dueling models!
> >>
> >> It's so fast to get netlogo models running, we almost always do a
> >> "silly" level-0 model that lets us get the algorithms right and then
> >> "the real" model .. and with one recent project, two "real models" ..
> >> one at a low resolution but with a large scope (zozobra with all of
> >> Ft Marcy park) and one at high resolution (zozobra with just the
> >> baseball diamond).
> >>
> >> This two-level approach is often very useful with client interaction
> >> as well .. we can show what we're doing and very quickly respond to
> >> feedback. Indeed, with the recent Stadium model we did, we weren't
> >> really sure which the client would go for until near the end of the
> >> project.
> >>
> >> -- Owen
> >>
> >> Owen Densmore
> >> http://backspaces.net - http://redfish.com - http://friam.org
> >>
> >>
> >> On Nov 21, 2005, at 8:47 AM, Owen Densmore wrote:
> >>
> >>> A surprising amount of our modeling is done with netlogo. RePast
> >>> used to be used quite a bit but we found that there was nothing we
> >>> could not do in netlogo, so due to RePast being more difficult to
> >>> program, we've settled happily on netlogo. It has the happy side
> >>> effect that more of the folks involved in the simulation can easily
> >>> read the code as well, and deploys simply in web pages.
> >>>
> >>> That said, I should mention that we do quite a bit outside of the
> >>> model itself. Stephen uses the model data in various visualization
> >>> packages to make the data far more understandable by clients. We
> >>> also find ourselves using statistics packages like R to analyze
> >>> parameter scans done in netlogo. This lets us output simple text
> >>> formatted data from netlogo and pass it on to more sophisticated
> >>> systems.
> >>>
> >>> Thus our view of simulation and modeling has become one of several
> >>> systems working in concert rather than a single package like RePast
> >>> or netlogo or the like.
> >>>
> >>> -- Owen
> >>>
> >>> Owen Densmore
> >>> http://backspaces.net - http://redfish.com - http://friam.org
> >>>
> >>>
> >>> On Nov 20, 2005, at 6:46 PM, Martin C. Martin wrote:
> >>>
> >>>>
> >>>>
> >>>> Russell Standish wrote:
> >>>>
> >>>>> What's it for? The website indicates its for website development,
> >>>>> but
> >>>>> unless that's what you do for a living, is it of interest? For
> >>>>> instance is it useful for doing simulations?
> >>>>>
> >>>>> Cheers
> >>>>>
> >>>>>
> >>>>
> >>>> Well, Ruby probably is.
> >>>>
> >>>> Out of curiosity, how many people here do simulations in a high
> >>>> level
> >>>> language (e.g. Java or C++) vs. a very high level language (like
> >>>> Ruby,
> >>>> Python or perl)?
> >>>>
> >>>> - Martin
> >>>>
> >>>>
> >>>> ============================================================
> >>>> FRIAM Applied Complexity Group listserv
> >>>> Meets Fridays 9a-11:30 at Mission Cafe
> >>>> Wed Lecture schedule, archives, unsubscribe, maps, etc. at http://
> >>>> www.friam.org
> >>>
> >>>
> >>> ============================================================
> >>> FRIAM Applied Complexity Group listserv
> >>> Meets Fridays 9a-11:30 at Mission Cafe
> >>> Wed Lecture schedule, archives, unsubscribe, maps, etc. at http://
> >>> www.friam.org
> >>
> >>
> >> ============================================================
> >> FRIAM Applied Complexity Group listserv
> >> Meets Fridays 9a-11:30 at Mission Cafe
> >> Wed Lecture schedule, archives, unsubscribe, maps, etc. at http://
> >> www.friam.org
> >
> > --
> > *PS: A number of people ask me about the attachment to my email, which
> > is of type "application/pgp-signature". Don't worry, it is not a
> > virus. It is an electronic signature, that may be used to verify this
> > email came from me if you have PGP or GPG installed. Otherwise, you
> > may safely ignore this attachment.
> >
> > ----------------------------------------------------------------------
> > ------
> > A/Prof Russell Standish Phone 8308 3119 (mobile)
> > Mathematics 0425 253119 (")
> > UNSW SYDNEY 2052 R.Standish at unsw.edu.au
> > Australia http://
> > parallel.hpc.unsw.edu.au/rks
> > International prefix +612, Interstate prefix 02
> > ----------------------------------------------------------------------
> > ------
> >
> > ============================================================
> > FRIAM Applied Complexity Group listserv
> > Meets Fridays 9a-11:30 at Mission Cafe
> > Wed Lecture schedule, archives, unsubscribe, maps, etc. at http://
> > www.friam.org
>
>
> ============================================================
> FRIAM Applied Complexity Group listserv
> Meets Fridays 9a-11:30 at Mission Cafe
> Wed Lecture schedule, archives, unsubscribe, maps, etc. at http://www.friam.org

Parks, Raymond

Ruby on Rails

In reply to this post by Giles Bowkett

Giles Bowkett wrote:

> If what you want is an applet compiled from C++, I don't think that
> exists. Exposing EcoLab to Java sounds like your best bet. I know
> virtually nothing about compilers, but I'd guess that compiling a
> not-garbage-collected language to a garbage-collected one could be a
> can of worms.
>
> Sorry, I was kind of just thinking out loud.
>
> On 11/22/05, Russell Standish <r.standish at unsw.edu.au> wrote:
>
>>Neither of these approaches solve the problem I was posing. The Flash
>>solution (IIUC) is basically posting a movie of a simulation - it
>>doesn't allow the user to muck around with parameters. I can already
>>do this, as there are recipes for exporting MPEG or AVI files from
>>EcoLab (as there is from RePast too, its not a terribly difficult concept).
>>
>>Nor do I want to host the C++ objects on a server. If I wanted to do
>>this, I could simply expose EcoLab objects to Java, and then provide a
>>Java applet that talks back to the EcoLab server. Its doable, although
>>not yet done 'coz its not what I want to do.
>>
>>Probabably what would solve it is a C++ -> JVM compiler. Do such
>>things exist? Could such things be developed from tools like GCC? The
>>closest thing to what I want is .NET, but .NET doesn't yet do it.

Sorry for the delayed reaction. In some previous work, I developed
Java applets that communicated with a C++ back end via CORBA. The
web-site which served the applets also ran a CORBA server. The applets
performed their display function based on data that they collected from
the CORBA server (written in C++) which in turn collected the data from
sensors in real-time. Probably the best common denominator that I know
for Java and C++ is the interface language used in CORBA.

--
Ray Parks rcparks at sandia.gov
IDART Project Lead Voice:505-844-4024
IORTA Department Fax:505-844-9641
http://www.sandia.gov/idart Pager:800-690-5288

Russell Standish

Ruby on Rails

What's wrong with Java Native Interface? CORBA is a bit heavy handed,
since I would drive the interface generation from Classdesc anyway.

Cheers

On Wed, Nov 30, 2005 at 02:39:42PM -0700, Raymond Parks wrote:

> Sorry for the delayed reaction. In some previous work, I developed
> Java applets that communicated with a C++ back end via CORBA. The
> web-site which served the applets also ran a CORBA server. The applets
> performed their display function based on data that they collected from
> the CORBA server (written in C++) which in turn collected the data from
> sensors in real-time. Probably the best common denominator that I know
> for Java and C++ is the interface language used in CORBA.
>
> --
> Ray Parks rcparks at sandia.gov
> IDART Project Lead Voice:505-844-4024
> IORTA Department Fax:505-844-9641
> http://www.sandia.gov/idart Pager:800-690-5288
>
>
> ============================================================
> FRIAM Applied Complexity Group listserv
> Meets Fridays 9a-11:30 at Mission Cafe
> lectures, archives, unsubscribe, maps at http://www.friam.org

Parks, Raymond

Ruby on Rails

Russell Standish wrote:

> What's wrong with Java Native Interface? CORBA is a bit heavy handed,
> since I would drive the interface generation from Classdesc anyway.

I'm sure it works fine for its purpose, which is to interface between
Java and the native code of the platform on which the JVM is executing.
My response was to a request for a method to get C++ and Java talking
closely.

In the application that I programmed, the Java applet ran on a system
in DC and my server ran on a platform at the Nevada Test Site. If I
recall, JNI was in an early state and even if it could handle that task,
now, it couldn't have done it then. This was in the early days of CORBA
and the actual solution was even more complex than I previously
simplified. The Java applet used CORBA to execute methods in a Java
application on the server, which in turn used CORBA to communicate with
the real application written in C++. It was one of those kludges that
you end up with when using bleeding-edge software and the vendor is
metaphorically scratching their head and plaintively complaining, "We
never thought anyone would do THAT."

Perhaps it is a sociological indicator of my professional nature that
I seem to frequently be in that situation. Put in another way, I don't
just think out of the box - I never got the memo saying that the box exists.

--
Ray Parks rcparks at sandia.gov
IDART Project Lead Voice:505-844-4024
IORTA Department Fax:505-844-9641
http://www.sandia.gov/idart Pager:800-690-5288