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:
Russell Thomas <[log in to unmask]>
Reply To:
MASON Multiagent Simulation Toolkit <[log in to unmask]>
Date:
Thu, 2 Jul 2015 11:41:30 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (117 lines)
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