MASON-INTEREST-L Archives

July 2015

MASON-INTEREST-L@LISTSERV.GMU.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Sadat Chowdhury <[log in to unmask]>
Reply To:
MASON Multiagent Simulation Toolkit <[log in to unmask]>
Date:
Thu, 2 Jul 2015 14:46:21 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (121 lines)
This sounds like a good idea — almost like double buffered animation — where the 2nd buffer is updated while the 1st is being rendered: but in this case the buffers are models. I’ll look at all these options — but I understood Russ’s suggestion more easily.

> On Jul 2, 2015, at 2:41 PM, Russell Thomas <[log in to unmask]> wrote:
> 
> Following the idea of "running N simulations in a row with occasional
> visualization", you could duplicate the objects that hold the agent state
> you want to visualize.  Assume this is an ObjectGrid2D.  You would have one
> for visualization (set up in the normal way, attached to a display window)
> and another one (or N, for each agent, if that is what you need) to hold the
> state of the simulation.
> 
> Create a Steppable object to count the number of simulation steps, and then
> at the specified number of steps, this object would copy the contents of
> your simulation grid to the visualization grid.  Since you are doing this
> very rarely, the extra overhead in the copy operation should not be a
> problem.
> 
> Using this solution would leave all the MASON GUI components unchanged and
> functioning normally. You wouldn't need to manually close and open a display
> window. The only thing updating in the GUI would be the step timer.  I'd
> guess that if you minimized the controller window, then you'd skip this
> overhead, too.
> 
> Russ
> 
> 
> On 7/2/15, 11:25 AM, "Sean Luke" <[log in to unmask]> wrote:
> 
>> The problem here is that graphical interface libraries like to be in control
>> of your main loop, but you're running an evolutionary computation system which
>> is probably going to be in control of the main loop.  So a few resources and
>> ideas.
>> 
>> First, note that if you've followed the rules regarding properly serializable
>> stuff, and you have no writeable shared or static variables,  you can probably
>> easily copy the entire runtime state of a MASON simulation using the
>> ec/util/DataPipe.java file found in the ECJ toolkit
>> (https://github.com/eclab/ecj/blob/master/ecj/ec/util/DataPipe.java).  Just
>> checkpoint into it, and then checkpoint out of it, and now you've got another
>> SimState.  You could probably use this to run stuff in the background, then
>> occasionally "clone" a simulation to use in the foreground while stuff is
>> still running in the background.
>> 
>> Second, if you weren't using an evolutionary computation facility, but rather
>> were just running N simulations in a row with occasional visualization, you
>> could easily hack something up to not display anything in the GUI (just
>> closing the windows) then occasionally pop up a display.
>> 
>> Here's what I'd do.  Let's say your model is of the class MyModel and your
>> visualization is of the class MyModelWithUI.  Do your evolutionary computation
>> loop, then when you want to view a simulation representing a current solution,
>> let's say that the simulation you want to see is called mymodel.  Then you
>> could say:
>> 
>> // copy it so we can still do things with mm in the background
>> // (if that matters to you)
>> MyModel mm = (MyModel)(DataPipe.copy(mymodel));
>> 
>> // display
>> MyModelWithUI mmwi = new MyModelWithUI(mysim);
>> Console c = new Console(mmwi);
>> c.setVisible();
>> 
>> ... then continue evolving in a separate thread in the background.
>> 
>> Sean
>> 
>> 
>> On Jul 2, 2015, at 2:03 PM, Sadat Chowdhury <[log in to unmask]> wrote:
>> 
>>> Ernesto,
>>> 
>>> I have considered checkpointing ‹ and that option is out. I really want a bit
>>> more control over the controller mechanism itself: I want to be able to
>>> detach and re-attach the model (and/or view) at will.
>>> 
>>> Checkpointing mechanism allows me to take snapshopts of my model and view it
>>> separately. Itąs intended to allow one to view a stored snapshot of the
>>> model, in case there are accidental failures or models that have run on
>>> different platforms‹ and thatąs all good ‹ but not what Iąm looking for.
>>> 
>>> -Sadat.
>>> 
>>>> On Jul 2, 2015, at 12:47 PM, Ernesto Carrella <[log in to unmask]> wrote:
>>>> 
>>>> I think what you are asking for is "checkpointing" which is implemented and
>>>> well described in the MASON manual (section 4.2.1 and the tutorial too)
>>>> although it requires every object to be serializable.
>>>> There might be other ways of storing java objects obviously but this is
>>>> native so it might be worth a try.
>>>> 
>>>> On Thu, Jul 2, 2015 at 5:43 PM Sadat Chowdhury <[log in to unmask]> wrote:
>>>> I probably asked this before.
>>>> 
>>>> My model is an evolutionary system that evolves agents towards some goal.
>>>> When I evolve each successive generation, I have to run N number of
>>>> simulations ‹  basically evaluating a population of N genotypes (N is
>>>> usually 512). By the time I get to the 100th generation, I would have run
>>>> 100N simulations.
>>>> 
>>>> I want to visualize the behavior of these agents (in the View) ‹ but I want
>>>> to just observe one simulation, every N simultions. In other words, I want
>>>> to visualize simulation number 1, simulation number N+1, simulation number
>>>> 2N+1, and so onŠ (it doesnąt have to be the first one, neccessarily, it
>>>> could be just any one from that set of N simulations).
>>>> 
>>>> Translated in the model-view-controller lingo:  I want the controller to
>>>> stop observing the model and rendering the view at certain points while
>>>> keeping the model running as usual. The reason for this should be obvious:
>>>> the model runs much much faster without graphics rendering ‹ and I want to
>>>> observe the progress much more efficiently by peeking into the model,
>>>> periodically.
>>>> 
>>>> Certain options are out: I donąt want to serialize and re-animate with a
>>>> separate łplayer˛ ‹ I want to observe real-time.
>>>> 
>>>> I am more than willing to get under the hood of MASON and directly work on
>>>> the source (e.g. Controller.java) ‹ all at my own risk, of course. What
>>>> would be nice is some idea on where I can momentarily łdetach˛ the view and
>>>> łre-attach˛ it again.

ATOM RSS1 RSS2