I need some help setting up a particular terrain. I have a world that is 200x200 patches and each patch has a size of 2 pixels. What I am trying to do is to make a hill starting at the origin, and then have the altitude evenly spread out to the edges of the world.
The origin would have around the highest altitude: 999, and patches around the edges would have the altitudes closes to 0. From the edges of the world, the altitude should constantly increase, until it gets to the origin However, I can't seem to get the hill to extend out to the edges of the world - there is a little bump in the middle, and the rest of the world is completely flat.
Can anyone help on setting up the terrain and explain how I can get the altitude to diffuse properly?
Here's the code I have so far:
patches-own [altitude]
to setup
clear-all
ask patch 0 0 [set altitude 1.0]
repeat 100 [diffuse altitude 0.25] ;; this needs to be changed?
scale-patches
color-patches
end
to scale-patches
let low [altitude] of min-one-of patches [altitude] ;; altitude of the lowest patch
let high [altitude] of max-one-of patches [altitude] ;; altitude of the highest patch
let range high - low ; difference from lowest to highest
ask patches [
set altitude altitude - low ; Shift every patch down so lowest altitude is 0
set altitude altitude * 999.0 / range ; Scale every patch so that the lowest is 0 and highest is 999
]
end
to color-patches
ask patches [set pcolor scale-color green altitude 0 1000]
end
How about replacing these two lines:
ask patch 0 0 [set altitude 1.0]
repeat 100 [diffuse altitude 0.25] ;; this needs to be changed?
with this:
ask patches [ set altitude world-width - distance patch 0 0 ]
It doesn't use diffusion, but maybe it solves your problem anyway?
Related
I'm trying to intoxicate bees by being near the flower. Toxicity is a flower-own variable, however, I want to add the number of said toxicity to the established mortality for the bees. I get the error that toxicity is not a bees variable, which is true, but how do I add this. The idea is that the flower has a set toxicity and if someone is near it gets intoxicated making them die faster. Thanks in advance, the code should work copy past.
breed [flowers flower]
breed [bees bee]
turtles-own
[
mortality
tipo_exposicion
t_supervivencia
]
flowers-own [toxicity]
to setup
clear-all
create-flowers 5
[
set shape "flower"
set color red
set size 4
move-to one-of patches
]
ask patches [set pcolor 63]
create-bees 100
[
setxy random-xcor random-ycor
]
ask bees
[
set shape "person"
set size 1
set color yellow
set t_supervivencia 0
]
ask flowers [set color gray]
reset-ticks
end
to go
ask bees [
move-bees
]
ask bees[intoxicarse]
ask flowers [ morir_bees_eating]
tick
end
to move-bees
right random 60
forward 1
set t_supervivencia t_supervivencia + 1
set mortality mortality + 1
end
to intoxicarse
ask bees in-radius 10 [if any? flowers with [color = gray][
set mortality mortality + toxicity]]
end
to morir_bees_eating
if color = gray [set toxicity 34]
end
Let me first "translate" what the intoxicarse procedure is doing right now:
It is called for any bee. So lets say first it calls the procedure on bee 1. Then, it looks for bees within a radius of 10 (ask bees in-radius 10). For every close bee, it will search in the set of all flowers (not just the close ones) if there are any gray ones. If there are any flowers in the world with gray color, all bees that are close to bee 1 would increase their mortality.
Here's a suggestion on how you could change your code:
create an agentset with let, that contains all close flowers with gray color. You can combine in-radius and with.
if there are close flowers (any?) then you can get their toxicity with of. One point, that isn't clear to me is, what happens, when there are more than one close flower. Should their toxicity sum up? Or should only one of the close flowers intoxicate the bee? You can use sum or one-of.
let close_flowers flowers in-radius 10 with [color = gray]
if any? close_flowers
[
let this_toxicity [toxicity] of one-of close_flowers ;get toxicity from one close flower
let this_toxicity sum [toxicity] of close_flowers ;sum of toxicity
set mortality mortality + this_toxicity
]
I would have the flowers call intoxicarse and write it more simply as
to intoxicarse
ask bees in-radius 10 [set mortality mortality + toxicity]
end
I'm trying to implement different types of lights in my ray-tracer coded in C. I have successfully implemented spot, point, directional and rectangular area lights.
For rectangular area light I define two vectors (U and V) in space and I use them to move into the virtual (delimited) rectangle they form.
Depending on the intensity of the light I take several samples on the rectangle then I calculate the amount of the light reaching a point as though each sample were a single spot light.
With rectangles it is very easy to find the position of the various samples, but things get complicated when I try to do the same with a disk light.
I found little documentation about that and most of them already use ready-made functions to do so.
The only interesting thing I found is this document (https://graphics.pixar.com/library/DiskLightSampling/paper.pdf) but I'm unable to exploit it.
Would you know how to help me achieve a similar result (of the following image) with vector operations? (ex. Having the origin, orientation, radius of the disk and the number of samples)
Any advice or documentation in this regard would help me a lot.
This question reduces to:
How can I pick a uniformly-distributed random point on a disk?
A naive approach would be to generate random polar coordinates and transform them to cartesian coordinates:
Randomly generate an angle θ between 0 and 2π
Randomly generate a distance d between 0 and radius r of your disk
Transform to cartesian coordinates with x = r cos θ and y = r sin θ
This is incorrect because it causes the points to bunch up in the center; for example:
A correct, but inefficient, way to do this is via rejection sampling:
Uniformly generate random x and y, each over [0, 1]
If sqrt(x^2 + y^2) < 1, return the point
Goto 1
The correct way to do this is illustrated here:
Randomly generate an angle θ between 0 and 2π
Randomly generate a distance d between 0 and radius r of your disk
Transform to cartesian coordinates with x = sqrt(r) cos θ and y = sqrt(r) sin θ
Id like to set the size of a turtle as the size of the patch it's standing on.
Even better I need turtles which are bigger as 4 or 16 patches.
If for example i have a squared world with 16x16 patches id like to have turtles that can be big 1x1 or 2x2 or 4x4 etc....
and the turtle should overlap perfectly the patches: it might be 1 patch (1x1 case), 4 (2x2 case) etc...
abott setting the size of the turtle equal to the sie of the patch for perfect overlapping in trying wit this code:
hatch-turtle 1 [set size [size] of patch-here ]
but it gives me the error:
A patch can't access a turtle variable without specifying which turtle.
Maybe try some variation of:
ask turtles [ set size patch-size ]
perhaps scaling by a multiplier as needed. Note that size is a per-turtle variable, but patch-size is a global reporter, because all patches are always the same size in pixels.
Note that size is measured in patches, while patch-size is measured in pixels.
I really don't understand at all what you're trying to do here, but the above is legal NetLogo code, anyway.
A turtle's size is measured in units of patches, so if you want your turtles to be the same size as the patches they are standing on, that's:
ask turtles [ set size 1 ]
but 1 is the default size, so in order to get this behavior, you actually don't need to do anything at all.
This answer comes years after the question was asked, but I leave it here hoping that it helps others who may encounter the same problem (as I did). Below I first clarify the problem and then offer a solution.
Clarification: It is implied by the problem that OP has defined a square shape for the turtles. The default size of square turtles in NetLogo is 1, which means that by default a square turtle should completely fill a patch. However, OP still observed blank space between square turtles that are placed next to each other. The aim of this answer is to remove that blank space for square turtles of size 1.
Solution: To solve this problem, note that the default square shape of turtles in NetLogo is made up of a colored inner area and a thick colorless border. The blank space that the OP observed between the turtles was in fact composed of the colorless borders of square shapes. In order to produce a figure with colored squares placed immediately adjacent to each other (that is, without any apparent space between them), it suffices to define a new square shape with no border. This new square shape should be defined such that the inner area of the square fills the entire patch. This can be done using the Turtle Shapes Editor from the Tools menu: find the square shape, create a duplicate of it, and modify the new shape in the graphical editor. To modify the shape, click on its top-left corner and drag that corner to the top-left corner of the graphical editor window. Then do the same with the bottom-right corner.
Currently I'm trying the following: I have points from google earth (WGS84) which I want to transform to a local x,y coordinate system: a tangential plane with y positive from south to north and x positive from west to east.
There is no need for the plane to be part of a global coordinate system more than the relation (x=0, y=0) = (lat,lon). The scale at which I'm working is in the order of say 100 kilometers (maximum of for example 200 km's). Very small errors (due to for example the curvature of the earth) are acceptable.
I have relatively little understanding of this topic as of yet. Can anybody help me out? Where would I need to look for example.
Thanks!
I haven't found the answer mathematically but have found that the package basemap (of the mpl_toolkit) should help with this respect (from wgs84 to a transverse mercator projection).
I'm trying to create a solar system simulation, and I'm having problems trying to figure out initial velocity vectors for random objects I've placed into the simulation.
Assume:
- I'm using Gaussian grav constant, so all my units are AU/Solar Masses/Day
- Using x,y,z for coordinates
- One star, which is fixed at 0,0,0. Quasi-random mass is determined for it
- I place a planet, at a random x,y,z coordinate, and its own quasi-random mass determined.
Before I start the nbody loop (using RK4), I would like the initial velocity of the planet to be such that it has a circular orbit around the star. Other placed planets will, of course, pull on it once the simulation starts, but I want to give it the chance to have a stable orbit...
So, in the end, I need to have an initial velocity vector (x,y,z) for the planet that means it would have a circular orbit around the star after 1 timestep.
Help? I've been beating my head against this for weeks and I don't believe I have any reasonable solution yet...
It is quite simple if you assume that the mass of the star M is much bigger than the total mass of all planets sum(m[i]). This simplifies the problem as it allows you to pin the star to the centre of the coordinate system. Also it is much easier to assume that the motion of all planets is coplanar, which further reduces the dimensionality of the problem to 2D.
First determine the magnitude of the circular orbit velocity given the magnitude of the radius vector r[i] (the radius of the orbit). It only depends on the mass of the star, because of the above mentioned assumption: v[i] = sqrt(mu / r[i]), where mu is the standard gravitational parameter of the star, mu = G * M.
Pick a random orbital phase parameter phi[i] by sampling uniformly from [0, 2*pi). Then the initial position of the planet in Cartesian coordinates is:x[i] = r[i] * cos(phi[i]) y[i] = r[i] * sin(phi[i])
With circular orbits the velocity vector is always perpendicular to the radial vector, i.e. its direction is phi[i] +/- pi/2 (+pi/2 for counter-clockwise (CCW) rotation and -pi/2 for clockwise rotation). Let's take CCW rotation as an example. The Cartesian coordinates of the planet's velocity are:vx[i] = v[i] * cos(phi[i] + pi/2) = -v[i] * sin(phi[i])vy[i] = v[i] * sin(phi[i] + pi/2) = v[i] * cos(phi[i])
This easily extends to coplanar 3D motion by adding z[i] = 0 and vz[i] = 0, but it makes no sense, since there are no forces in the Z direction and hence z[i] and vz[i] would forever stay equal to 0 (i.e. you will be solving for a 2D subspace problem of the full 3D space).
With full 3D simulation where each planet moves in a randomly inclined initial orbit, one can work that way:
This step is equal to step 1 from the 2D case.
You need to pick an initial position on the surface of the unit sphere. See here for examples on how to do that in a uniformly random fashion. Then scale the unit sphere coordinates by the magnitude of r[i].
In the 3D case, instead of two possible perpendicular vectors, there is a whole tangential plane where the planet velocity lies. The tangential plane has its normal vector collinear to the radius vector and dot(r[i], v[i]) = 0 = x[i]*vx[i] + y[i]*vy[i] + z[i]*vz[i]. One could pick any vector that is perpendicular to r[i], for example e1[i] = (-y[i], x[i], 0). This results in a null vector at the poles, so there one could pick e1[i] = (0, -z[i], y[i]) instead. Then another perpendicular vector can be found by taking the cross product of r[i] and e1[i]:e2[i] = r[i] x e1[i] = (r[2]*e1[3]-r[3]*e1[2], r[3]*e1[1]-r[1]*e1[3], r[1]*e1[2]-r[2]*e1[1]). Now e1[i] and e2[i] can be normalised by dividing them by their norms:n1[i] = e1[i] / ||e1[i]||n2[i] = e2[i] / ||e2[i]||where ||a|| = sqrt(dot(a, a)) = sqrt(a.x^2 + a.y^2 + a.z^2). Now that you have an orthogonal vector basis in the tangential plane, you can pick one random angle omega in [0, 2*pi) and compute the velocity vector as v[i] = cos(omega) * n1[i] + sin(omega) * n2[i], or as Cartesian components:vx[i] = cos(omega) * n1[i].x + sin(omega) * n2[i].xvy[i] = cos(omega) * n1[i].y + sin(omega) * n2[i].yvz[i] = cos(omega) * n1[i].z + sin(omega) * n2[i].z.
Note that by construction the basis in step 3 depends on the radius vector, but this does not matter since a random direction (omega) is added.
As to the choice of units, in simulation science we always tend to keep things in natural units, i.e. units where all computed quantities are dimensionless and kept in [0, 1] or at least within 1-2 orders of magnitude and so the full resolution of the limited floating-point representation could be used. If you take the star mass to be in units of Solar mass, distances to be in AUs and time to be in years, then for an Earth-like planet at 1 AU around a Sun-like star, the magnitude of the orbital velocity would be 2*pi (AU/yr) and the magnitude of the radius vector would be 1 (AU).
Just let centripetal acceleration equal gravitational acceleration.
m1v2 / r = G m1m2 / r2
v = sqrt( G m2 / r )
Of course the star mass m2 must be much greater than the planet mass m1 or you don't really have a one-body problem.
Units are a pain in the butt when setting up physics problems. I've spent days resolving errors in seconds vs timestep units. Your choice of AU/Solar Masses/Day is utterly insane. Fix that before anything else.
And, keep in mind that computers have inherently limited precision. An nbody simulation accumulates integration error, so after a million or a billion steps you will certainly not have a circle, regardless of the step duration. I don't know much about that math, but I think stable n-body systems keep themselves stable by resonances which absorb minor variations, whether introduced by nearby stars or by the FPU. So the setup might work fine for a stable, 5-body problem but still fail for a 1-body problem.
As Ed suggested, I would use the mks units, rather than some other set of units.
For the initial velocity, I would agree with part of what Ed said, but I would use the vector form of the centripetal acceleration:
m1v2/r r(hat) = G m1 m2 / r2 r(hat)
Set z to 0, and convert from polar coordinates to cartesian coordinates (x,y). Then, you can assign either y or x an initial velocity, and compute what the other variable is to satisfy the circular orbit criteria. This should give you an initial (Vx,Vy) that you can start your nbody problem from. There should also be quite a bit of literature out there on numerical recipes for nbody central force problems.