I'm studying NetLogo and have a question about some specific point that I could not find answer. Overall, I am trying to write a program that has these features:
Two country flag
First country flag will move 1.B, 2.C, 3.D from A city (stop at D)
Second country flag will move E from G city
Second country flag will move G from D city
While first country moving these city. The flag drop army (For instance Starting 100k soldier at A . It will 90k at B and C 80k etc.)
When they meet at D city at same time first country flag lose all soldier.
I want to plot the number of soldiers depending on time. Time / Number PLOT
I need only setup and go buttons if it possible.
I am starting with just moving the first flag, based on a program that is included in the library.
In this part I am trying to create different cities with different locations.
to setup
clear-all
set-default-shape houses "house"
;; CREATE-ORDERED-<BREEDS> distributes the houses evenly
create-ordered-houses number-of-city
[ setxy 5 4 ] ;; B
create-ordered-houses number-of-city
[ setxy 1 4 ] ;; C
create-ordered-houses number-of-city
[ setxy 11 6 ] ;; D
In this part I'm trying to create flags
create-people number-of-people [
setxy -8 10 ;; A city for first flag
set target one-of houses
facexy 5 4
This is the part I'm trying to understand (Copied from library ). It's about movement of the first flag.
ask people [
;; if at target, choose a new random target
if distance target = 0
[ set target one-of houses
face target ]
;; move towards target. once the distance is less than 1,
;; use move-to to land exactly on the target.
ifelse distance target < 1
[ move-to target ]
[ fd 1 ]
When I run with this code, the first flag moves to the wrong place. I explain my problem in this picture.
Movement of my first flag
I think you are adapting code that only has one possible target. In that code, it is fine to use one-of to select the target because there's only one choice. In your adaptation, however, there's more than one choice. So when you create the flag in your second block of code...
set target one-of houses
facexy 5 4
... you are choosing a random target from any of the four houses, and then facing house B (which is at 5 4). Let's say the random choice (one-of) picked house C. You flag moves towards B because you told it to face (5 4) and then move forward, but your test for whether it gets close is distance to the target (that is, distance to C if that's the one that was randomly chosen).
Try changing that piece of code to:
set target one-of other houses
facexy target
This code will make the flag go to a randomly selected house that is not the house they are currently at. Since you actually want them to go in a particular order, you will have to do something like give each house a name (that is, create a houses-own attribute to identify each one) and then have the flag do something like set target house with [ name = 'B' ]. However, make this change after you have everything about moving working. Your general approach of adding a little bit at a time is correct - get it moving to any target and then worry about moving to the correct target.
Related
I'm trying to optimize a pick and place problem based on the previous robot positions.
Let's assume that all the positions, which represents working stations, are numbered from 0 to 5 and there's a SCARA robot between them. Every position does need some fixed time to process that piece and the piece must go to all stations before we can call it done . A PLC controls all of this process so it knows when a piece is ready somewhere inside one of these stations and sends the robot there to pick it. It is also important to know that stations 2,3,4 do the same process so a part must go either to station 2, 3 or 4 and then to station 5. So the first part comes to position 0 (position 0 generates parts), the robot picks that part and places it to position 1. After a fixed time the robot takes that part and moves it to station 2. Now the position 1 is empty so the robot takes a part from position 0 and puts it into position 1. Every movement of the robot takes a small time but not 0, which affects the whole process cycle time. I'm trying to include that robot movement time into the parts processing time so when a piece is ready inside a station, the robot should be right there ready to pick it and place it somewhere else.
A real experiment based on 5 stations numbered 0 to 5 gives the following order of the positions:
0-1, 1-2, 0-1, 2-5, 1-2, 0-1, 1-3, 0-1, 2-5, 1-2, 0-1, 1-3 ...
The positions can be grouped because once a part is picked (the digit before '-') i know where it will be placed (the digit after) .
How can I estimate the next picking point so that the robot can move itself there before the plc tells it to ?
I don't know if your robot has any resources for this... If it doesn't, you can probably do it on your PLC.
Since the time of your process in each station is fixed, I'm thinking of using 5 or 6 separate timers, one for each station. Once the robot leaves the part in place you could start the specific timer for that station. When the robot is idle, it consults the remaining time of each one and goes to the one with the shortest time to complete.
This could be improved if you have a way to calculate (or look up in a list) the travel time from the current point to the station that is about to end... for example, the robot is at station 0 and station 1 is at 1.0 s from finishing and station 5 is 0.99999s from finishing... it would probably be more efficient to go to position 1 (closer) instead of going to position 5 (far).
Obviously this won't work if you don't know how long the part will take to be available at one of the stations, but in that case if you use a buffer to calculate the average waiting time of a part at a station (in which case you would have a sensor or something to check), you could estimate that the part is about to be ready using timers as well.
I am trying to create a game in which procedural generation will be like The Binding of Isaac one : successive rooms selected from a list. I think I will be able to link them together and all, but I have a problem : How do I choose a room from a list ?
My first thought is to create folders containing scenes, something like
zone_1
basic_rooms
room_1.tscn
room_2.tscn
special_rooms
...
zone_2
...
and to select a random scene from the folder I need, for example a random basic room from the first zone would be a random scene from zone_1/basic_rooms.
The problem is that I have no idea if this a good solution as it will create lots of scenes, and that I don't know how to do this properly. Do I simply use a string containing the folder path, or are there better ways ? Then I suppose I get all the files in the folder, choose one randomly, load it and instanciate it, but again, I'm not sure.
I think I got a little lost in my explainations, but to summarize, I am searching for a way to select a room layout from a list, and don't know how to do.
What you suggest would work.
You can instance scene by this pattern:
var room_scene = load("res://zone/room_type/room_1.tscn")
var room_instance = room_scene.instance()
parent.add_child(room_instance)
I'll also remind you to give a position to the room_instance.
So, as you said, you can build the string you pass to load.
I'll suggest to put hat logic in an autoload and call it where you need it.
However, the above code will stop the game while it is loading the scene. Instead do Background Loading with ResourceLoader.
First you need to call load_interactive which will give you a ResourceInteractiveLoader object:
loader = ResourceLoader.load_interactive(path)
Then you need to call poll on the loader. Until it returns ERR_FILE_EOF. In which case you can get the scene with get_resource:
if loader.poll() == ERR_FILE_EOF:
scene = loader.get_resource()
Otherwise, it means that call to poll wasn't enough to finish loading.
The idea is to spread the calls to poll across multiple frames (e.g. by calling it from _process).
You can call get_stage_count to get the number of times you need to call poll, and get_stage will tell you how many you have called it so far.
Thus, you can use them to compute the progress:
var progress = float(loader.get_stage()) / loader.get_stage_count()
That gives you a value from 0 to 1. Where 0 is not loaded at all, and 1 is done. Multiply by 100 to get a percentage to display. You may also use it for a progress bar.
The problem is that I have no idea if this a good solution as it will create lots of scenes
This is not a problem.
Do I simply use a string containing the folder path
Yes.
Then I suppose I get all the files in the folder, choose one randomly
Not necessarily.
You can make sure that all the scenes in the folder have the same name, except for a number, then you only need to know how many scenes are in the folder, and pick a number.
However, you may not want full randomness. Depending on your approach to generate the rooms, you may want to:
Pick the room based on the connections it has. To make sure it connects to adjacent rooms.
Have weighs for how common or rare a room should be.
Thus, it would be useful to have a file with that information (e.g. a json or a csv file). Then your autoload code responsible for loading scenes would load that file into a data structure (e.g. a dictionary or an array), from where it can pick what scene to load, considering any weighs or constraints specified there.
I will assume that your rooms exist on a grid, and can have doors for NORTH, SOUTH, EAST, WEST. I will also assume that the player can backtrack, so the layout must be persistent.
I don't know how far ahead you will generate. You can choose to generate all the map at once, or generate rooms as the player attempt to enter, or generate a few rooms ahead.
If you are going to generate as the player attempts to enter, you will want an room transition animation where you can hide the scene loading (with the Background Loading approach).
However, you should not generate a room that has already been generated. Thus, keep a literal grid (an array) where you can store if a room has been generated. You would first check the grid (the array), and if it has been generated, there is nothing to do. But if it hasn't, then you need to pick a room at random.
But wait! If you are entering - for example - from the south, the room you pick must have a south door to go back. If you organize the rooms by the doors they have, then you can pick from the rooms that have south doors - in this example.
In fact, you need to consider the doors of any neighbor rooms you have already generated. Thus, store in the grid (the array) what doors the room that was generated has. So you can later read from the array to see what doors the new room needs. If there is no room, decide at random if you want a door there. Then pick a room at random, from the sets that have the those doors.
Your sets of rooms would be, the combinations of NORTH, SOUTH, EAST, WEST. A way to generate the list, is to give each direction a power of two. For example:
NORTH = 1
SOUTH = 2
EAST = 4
WEST = 8
Then to figure out the sets, you can count, and the binary representation gives the doors. For example 10 = 8 + 2 -> WEST and SOUTH.
Those are your sets of rooms. To reiterate, look at the already generated neighbors for doors going into the room you are going to generate. If there is no room, decide at random if you want a door there. That should tell you from what set of rooms you need to pick to generate.
This is similar to the approach auto-tile solution use. You may want to read how that works.
Now assuming the rooms in the set have weights (so some rooms are more common and others are rarer), and you need to pick at random.
This is the general algorithm:
Sum the weights.
Normalize the weights (Divide the weights by the sum, so they add up to 1).
Accumulate the normalized weights.
Generate a random number from 0 to 1, and what is the last accumulated normalized weight that is greater than the random number we got.
Since, presumably, you will be picking rooms from the same set multiple times, you can calculate and store the accumulated normalized weights (let us call them final weights), so you don't compute them every time.
You can compute them like this:
var total_weight:float = 0.0
for option in options:
total_weight = total_weight + option.weight
var final_weight:float = 0.0
var final_weights:Array = []
for option in options:
var normalized_weight = option.weight / total_weight
final_weight = final_weight + normalized_weight
final_weights.append(final_weight)
Then you can pick like this:
var randomic:float = randf()
for index in final_weights.size():
if final_weights[index] > randomic:
return options[index]
Once you have picked what room to generate, you can load it (e.g. with the Background Loading approach), instance it, and add it to the scene tree. Remember to give a position in the world.
Also remember to update the grid (the array) information. You picked a room from a set that have certain doors. You want to store that to take into account to generate the adjacent rooms.
And, by the way, if you need large scale path-finding (for something going from a room to another), you can use that grid too.
I'm trying to adapt the (simple) Preferential Attachment Network model (available in the Netlogo Models library) to include a slider variable that determines network structure. According to the theory of the Preferential Attachment model (or 'Opinion Leader' model) each individual in the network is assigned a number of ties, k, according to the distribution p(k) ∝ k^−γ, and connected randomly to this number of people. I thus want to have a slider for which i can adapt γ.
In the heart of the original code partners and links are chosen randomly, as such:
to go
if count turtles > num-nodes [ stop ]
;; choose a partner attached to a random link
;; this gives a node a chance to be a partner based on how many links it has
;; this is the heart of the preferential attachment mechanism
let partner one-of [both-ends] of one-of links
;; create new node, link to partner
create-turtles 1 [
set color red
;; move close to my partner, but not too close -- to enable nicer looking networks
move-to partner
fd 1
create-link-with partner
]
;; lay out the nodes with a spring layout
layout
tick
end
I'm a bit lost on how I should include this parameter.
Anyone who could help?
Thanks in advance.
EDIT: still can't get this to work. I got as far as making a 'normal' preferential attachment model in setup rather than go (again adapted from the models library). But still can't get my head around how I should adapt this code to include the gamma parameter. My code:
to create-new-nodes [n]
clear-all
ask patches [ set pcolor white ]
create-nodes n [
set color red
set shape "circle"
]
reset-ticks
end
to wire-pref-attach
create-new-nodes 2 ; create the first two nodes (0 and 1)
ask node 0 [ create-edge-with node 1] ; link them together
create-nodes num-nodes - 2 [
create-edge-with [one-of both-ends] of one-of edges ; pref select old node with more links
set color red
set shape "circle"
]
radial-layout
end
to radial-layout
layout-radial nodes edges (node 0)
end
Help is very much appreciated!
I think you have missed the point of my original comment, there is no place in the Barabasi-Albert (BA) algorithm to insert any such parameter. You need to build the network in an entirely different way. That is, you need to work out the method or process or algorithm for building the network, and then worry about writing the code to implement that method.
I think you need the algorithm described in Dorogovtsev et al (2000) Structure of Growing Networks with Preferential Linking (see https://journals.aps.org/prl/pdf/10.1103/PhysRevLett.85.4633 if you have access). In the BA algorithm, the nodes in the existing network for the new node to attach to are selected with probability proportional to in-degree (or k in your question). In the extended algorithm, each node has an inherent attractiveness A and the probability of selection is instead A+k.
Equation 12 in the paper describes the relationship between the exponent (your parameter gamma as: gamma = 2 + A/m where m is the out-degree (the number of edges being attached with each node).
I would like to optimize my netlogo code and did this by using the profiler extension to track down bottlenecks. Furthermore, I am running my model in headless mode, which I give 2 GB of RAM (-Xmx2048m), and have 2601 patches with around 100-1500 agents. I use the time extension for netlogo.
Now, I have four general questions.
1) Is it better to write the exit conditions (see down below) within the model (in .nlogo) or in BehaviorSearch (which I use with the .xml file in headless mode), or does it not make any difference?
Within the Model:
if count turtles = 0 [ stop ]
if time:is-equal dt (time:create "1722-04-05") [ stop ] ;using the time extension
Within BehaviorSpace:
<exitCondition>count turtles = 0</exitCondition>
<exitCondition>time:is-equal dt (time:create "1722-04-05")</exitCondition>
2) I think I could optimize my model to the extent that it hardly runs faster by optimizing the code (see screenshot which I took after 6,5 hours of simulations running):
But, I am getting more and more doubtful about the way I scale each tick to represent a day in my model (which is actually a crucial element). I am getting doubtful because the maximal time span possible in my model would be 472 years. That would make 172280 ticks for a complete run of the model! I do not know if having a lot of ticks per run in Netlogo can be a huge bottleneck given the performance I have (see profiler output above).
3) Would it be reasonable to add the gpu extension into the model to gain more speed or is it not so easy to implement that? I ask because I have not found any documentation about that. This possibility(?) seems to be largely ignored, see this thread.
4) Would it make sense and would it be technically possible to run netlogo-headless in RAM? You might already see upon these questions that I am not really firm about such technicalities but interested about the possibilities.
Edit:
Down below you find the code snippet of orientation as requested:
to orientation
ifelse (energy < 4) [ ;if hungry
let nearest-resource min-one-of (patches with [pcolor = green] in-radius 3 ) [ distance myself ] ;check distance between you and nearest resource (3 fields 360 degrees view)
if is-patch? nearest-resource [ ;if green patch exist at all
move-to nearest-resource ]
]
[ rt random-float 30 - random-float 30 ] ;otherwise just walk randomly around
end
This part of the code has been subject of a recent discussion here on stackoverflow.
Thanks for posting your code! Luckily, it can be optimized! patches with [pcolor = green] will iterate through every single patch, checking to see which are green. ... in-radius 3 will iterate through all the green ones, checking to see which are close enough. However, if you do patches in-radius 3 first, NetLogo can compute exactly which patches are in that radius without having to check them all. Then, there are far fewer patches to check the color of as well. I got an almost 10x speedup from swapping the order of those:
to orientation
ifelse (energy < 4) [ ;if hungry
let nearest-resource min-one-of (patches in-radius 3 with [pcolor = green] ) [ distance myself ] ;check distance between you and nearest resource (3 fields 360 degrees view)
if is-patch? nearest-resource [ ;if green patch exist at all
move-to nearest-resource ]
]
[ rt random-float 30 - random-float 30 ] ;otherwise just walk randomly around
end
You have to be careful with querying on patches since there are typically a lot of patches. Doing in-radius checks before other checks can help a lot, since NetLogo can optimize patches in-radius.
Quick answers to your questions:
Shouldn't make a difference, but I like to put mine in BehaviorSpace.
More ticks alone is not necessarily bad. See Ising for example.
Haven't used it, but I would be really surprised if it worked. The last commit was over 4 years ago, which is many NetLogo versions ago. That said, if you get it working, I'd love to know!
Not exactly sure what you mean, but NetLogo runs entirely RAM. That said, if NetLogo and other programs running at the same time are using more memory than you have RAM, the OS will offload memory onto the hard drive, which can cause a serious slowdown in some cases. This is unlikely, but can definitely be a concern with super huge models (which yours is not). How much RAM does your computer have?
Finally, make sure you're letting BehaviorSpace use one thread per core on your machine. This is the default, so unless you're setting the number of threads, it should be happening. To be sure, each core should be close to 100% when running NetLogo. Your OSes activity monitor should be able to give you this information. If this is not happening (perhaps NetLogo is incorrectly detecting the number of cores), you can try setting the --threads option explicitly.
I am looking for a solution for a task similar to the Tower of Hanoi task, however this is different from Hanoi as the disks are not constrained by size. The Tower of London task I am creating has 8 disks, instead of the traditional 3 or 5 (as shown in the Wikipedia link). I am using PEBL software that is "programmed primarily in C++ (although you do not need to know C++ to use PEBL), but also uses flex and bison (GNU versions of lex and yacc) to handle parsing."
Here is a video of what the task looks like in action: http://www.youtube.com/watch?v=IiBJ94HRpeM&noredirect=1
*Each disk is a number. e.g., blue disk=1, red disk = 2, etc.
1 \
2 ----\
3 ----/ 3 1
4 5 / 2 4 5
========= =========
The left side consists of the disks you have to move, to match the right side. There are 3 columns.
So if I am making it with 8 disks, I would create a trial to look like this:
1 \
2 ----\ 7 8
6 3 8 ----/ 3 6 1
7 4 5 / 2 4 5
========= =========
How do I figure out what is the minimum amount of moves needed for the left to look like the right? I don't need to use PEBL to code this, but I need to know since I am calculating how close to the minimum a person would get for each trial.
The principle is easy and its called breadth first search:
Each state has a certain number of successor states (defined by the moves possible).
You start out with a set of states that contains the initial state and step number 0.
If the end state is in the set of states, return the step number.
Increment the step number.
Rebuild the set of states by replacing the current states with each of their successor states.
Go to 2
So, in each step, compute the successor states of your currently available states and look if you reached the target state.
BUT, be warned, this can take a while and eat up a lot of memory!
You can optimize a bit in our case, since you can leave out the predecessor state.
Still, you will have 5 possible moves in most states. Which means you will have 5^N states to consider after N steps.
For example, your second example will need 10 moves, if I don't err. This will give you about 10 million states. Most contemporary computers will not be able to search beyond depth 15.
I think that an algorithm to find a solution would be easy and fast, but we have no proof this solution would be the shortest one.