NetLogo / LevelSpace

This is the LevelSpace extension repository. LevelSpace allows you to run NetLogo models |: from inside NetLogo models :|
Other
19 stars 8 forks source link

Support transferring and cloning of agents between models #69

Open qiemem opened 8 years ago

qiemem commented 8 years ago

Turtles:

Patches:

Links:

arthurhjorth commented 8 years ago

I like this idea. I think we tried solving it a few years ago with agents as first order LevelSpace objects. I'd really like to see some implementation of it. My thoughts:

ls:move <source-model> <reporter-of-turtle/turtleset> <target-mode> <optional-initialization-block>

This assumes a Controller type model that moves agents between child mdoels. We should allow for moving from the current model to child models too. See below for a suggested solution.

Can transfer/clone (kill in one, create in another) between models with the same turtle/breed variable names.

It's possible that people want concurrent representations in different models of the same agent. I think we should not kill, but only clone. It's easy enough for people to kill a turtle in NetLogo anyway.

My suggestion would therefore be to split into a command a reporter. The reporter reports a TPL-set. The command takes one and clones.

Speaking of which...

That is, can copy if: [.....]

I'd love this to be more flexible. Can we add a variable to agents that isn't declared in -own called variables or something? That way we can clone all data that exists in the model, and put the rest in a key-value map? If that is possible, we can do stuff with an agent in model a, clone it to model b and have it do stuff, and then send it back to model a with some updated information based on what happened in model b, but without losing information.

Position is tough [...]

I don't think it is. I think your suggestion addresses everything that should be addressed, and I agree 100%.

arthurhjorth commented 8 years ago

Something like

let ls-agentset ls:agent-set turtles with [color = red]
ls:clone-agents <model-id> ls-agentset [ command-block ]

I am trying to wrap my head around potential ClassLoader issues with passing this to other LevelSpace extension objects. Maybe I shouldn't?

edit: no wait, I definitely should. We will have ClassLoader issues if we want to let people clone to other LS extension objects, i.e. across more than one generation, or even within generation depending on the structure of the model ecology. So that's something to consider too.

qiemem commented 8 years ago

I was hoping to keep it all in one procedure exactly to avoid dealing with custom levelspace objects so we don't have to deal with classloader issues.

How about an ls:self to allow cloning and transferring with the parent? e.g.

ls:clone-agents ls:self [turtles with [ color = red]] child-model [ initialization ]
qiemem commented 8 years ago

Map thing:

Let's do compatible models first. It's a strict problem. We'll want that to work as described no matter what. The map thing is pretty tough. We can add turtle variables, so we have to store in the extension itself. But then you could end up with more than one map per turtle when having >2 levels.

SethTisue commented 8 years ago

I'm picturing https://en.wikipedia.org/wiki/Wood_between_the_Worlds . disoriented turtles waking up with rings taped to their shells

arthurhjorth commented 8 years ago

I don't know if @SethTisue meant it (mostly?) as a joke, but I actually really like that analogy. I also like the post-hexy milestone.