Menu
▾
▴
Re: [Repast-interest] Repast HPC objects access
|
From: Kashif Z. <ka...@pe...> - 2011-12-20 16:15:21
|
John,
Please provide mw with exact fix to the angle problem based on the code
below. Because I have tried to do the same fix in last line. But before that
I have tried to reorient the angle calculated with horizontal (second last
line).
int nx =
npatch->pxCor();
int ny = npatch->pyCor();
int mx = pxCor();
int my = pyCor();
double dx = mx - nx;
double dy = my - ny;
double o = (atan2(dy, dx)) * 180 /
PI;
double oo = 180 + o - 90;
if (oo < 180) {oo = 180 + oo;}
else{oo = oo - 180;}
For network, I would try to do it with second option. But I do not know how
a grid model will work with network model.
Best
---
Kashif Zia
PhD Candidate
Institut für Pervasive Computing, Johannes Kepler Universität Linz,
Altenberger Straße 69, A-4040 Linz
Room: P105, Phone: +43-732-2468-9673, Fax: +43-732-2468-8426
E-Mail: ka...@pe...
-----Original Message-----
From: Murphy, John T. [mailto:jtm...@an...]
Sent: Tuesday, December 20, 2011 4:53 PM
To: Kashif Zia
Subject: Re: [Repast-interest] Repast HPC objects access
Kashif,
Regarding angles, the answer is that there was a bug in the last release of
Repast HPC; when given two points, P1 and P2, the 'getDisplacement' method
(in BaseGrid.h) incorrectly returned the displacement from P2 to P1 instead
of P1 to P2. This propagated downward through several function calls, so
that 'towards' and 'face' came out reversed (180-degrees off). I actually
saw that you were correcting for this in some earlier code you sent, so we
again thank you for helping us find another problem. This will be corrected
in the next release (which is in final testing, but won't be released until
after the holiday shutdown here at Argonne, so in early January).
Regarding your main question, it looks to me like you are attempting to
calculate values for agent decisions and movement once per patch, presumably
so that you do not have to calculate them for every agent. You are using
patches to create a value surface that tells the agents what to do. Some of
these decisions must be made on global information (density), so you want a
way to exchange that information as well. You are correct that a 'network'
of central patches would work.
One issue is a known limitation in the 'Relogo' version of Repast HPC: it is
not (currently) possible to create networks of agents across processes
within the 'Relogo' idiom. You can create networks (look in the API for
information about creating networks, etc.) of agents that are all on the
same process, but note that there is another change coming in the next
release that will make it possible to specify the existence of networks in a
Relogo 'properties' file, which is not possible right now. This, however,
does not address connecting agents in a network across processes.
Here are some solutions:
1) Create agents on one process, connect them in a network on that process,
and then move them to the processes where they really need to be. You would
probably end up using something other than a 'patch' agent for this (patches
generally don't move), so you'd have to create code that links this new
agent to the central patches after they get to the processes. But Repast
HPC/Relogo should manage the information exchange after that.
2) You can write code that uses Repast HPC's network functions by following
the example in the 'Rumor Model'. This is not a Relogo model, so you are
breaking out of Relogo's semantics, but the code will work and you can
connect a network of agents across processes. The key points to look at are
the places where agents are 'requested' from other processes before the
network is built. In your case, you could have each process request all the
central patches from the other processes, connect them in a network, and
then use the network synchronization routines to exchange the data.
3) If you really are exchanging just one value from all processes, so that
each process ends up with a copy of the value from all other processes, you
can use an MPI Alltoall; you probably would better off in the long term
finding a more flexible solution, but this one could be a good fix for a
unique problem.
Hope this gets you started- let us know.
Best,
John
--
John T. Murphy
Computational Postdoctoral Fellow
Decision and Information Sciences and
Argonne Leadership Computing Facility
Argonne National Laboratory
jtm...@an...
From: Kashif Zia <ka...@pe...<mailto:ka...@pe...>>
Date: Tue, 20 Dec 2011 09:15:41 -0600
To: 'Kashif Zia' <ka...@pe...<mailto:ka...@pe...>>,
"Murphy, John T." <jtm...@an...<mailto:jtm...@an...>>,
"rep...@li...<mailto:rep...@li...urcefo
rge.net>"
<rep...@li...<mailto:rep...@li...urcefo
rge.net>>
Subject: RE: [Repast-interest] Repast HPC objects access
Dear John,
Scenario:
1. We are taking a rater map of a city and converting it to a grid with
patch variables describing the structural features. Supposing that there are
Point of Attractions (POA) where agents want to go to, some of the processes
may have those POA as well.
2. Now before working with agents, I want to make sure that patches
have the correct information which would support decision making later on.
The minimum that we require is that each patch know distance and directions
of all POA. We have collections in patches of type std::map. And I am able
to connect the patches across the processes. For example, patch x may have
following information:
3. Direction-of-motion (DOM):
a. POA at process 0 -> 270 degree
b. POA at process 11 -> 315 degree
c. ....
4. Hop-count (HP):
a. POA at process 0 -> 2
b. POA at process 11 -> 24
c. ....
5. The agents would be populated in random number and at random places
which allow it. This physical layer (patches) is ready which can be used to
implement decision towards nearest POA.
6. The central patch of each process have a variable "DecisionValue"
which may have some state of processes, e.g. density (agents count). This
variable must be known to all the processes (and agents within) to realize
our future models. This refer back to our question 2. Juts describing it
explicitly here so that the problem in clear. The problem is that the
density would be decreasing all the time, so we have to pass this
information in each time stamp. And it would be obsolete if propagated and
shared through buffers. And the space is huge and we cannot perform a space
synchronization before each move of agents. In fact, to save the time, we
propagate the DOM and HP information periodically too. So agents would not
do anything (or so something local) unless they receive actionable info.
7. We have a tiny problem in populating the DOM as well which replaces
question 1.
Question 1:
How the angles in repast are managed (point of reference). For example if I
have to use towards or towardsxy, its automatic. But to find angles between
patches compatible with towards methods is confusing. I am doing it like
following:
int nx = npatch->pxCor();
int ny = npatch->pyCor();
int mx = pxCor();
int my = pyCor();
double dx = mx - nx;
double dy = my - ny;
double o = (atan2(dy, dx)) * 180 /
PI;
double oo = 180 + o - 90;
if (oo < 180) {oo = 180 + oo;}
else{oo = oo - 180;}
The last two lines are there to make them compatible with my understanding
of angles as I use them in NetLogo. But this seems to be incorrect, as
agents are not moving based on this information correctly.
Question 2: I need to have a "network" of central patches exchanging
information with each other. See above
That's it for the time being. Thanks for all the support and an excellent
Repast HPC.
Best Regards.
---
Kashif Zia
PhD Candidate
Institut für Pervasive Computing, Johannes Kepler Universität Linz,
Altenberger Straße 69, A-4040 Linz
Room: P105, Phone: +43-732-2468-9673, Fax: +43-732-2468-8426
E-Mail: ka...@pe...<mailto:ka...@pe...>
|