Re: [Repast-interest] Extending Patch class in Repast HPC

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Kashif,

Thanks for this; this makes some things a lot clearer.

You are correct about Rumor Model; the graph network is initialized
explicitly at startup and managed by RepastHPC through the course of the
running simulation.

You are also correct that there is no 'explicit' assignment of cells to a
particular processor. ReLogo does this automatically and implicitly. It
begins with the properties file: min.x, min.y, max.x, and max.y
properties. These are the properties for the entire world that is being
defined: the  maximum and minimum extents of the x and y directions are
given. Then it looks at the proc.per.x and proc.per.y properties. It uses
these to create a grid that divides up the whole landscape into a
cartesian grid. So, if:

min.x = -100
min.y = -100
max.x = 101
max.y = 101

proc.per.x = 10
proc.per.y = 5

Then the space is 200 x 200, and it is divided up into a 10 x 5 Cartesian
grid, with each of the 50 elements on this grid going on a different
processor. This is why if proc.per.x = X and proc.per.y = Y, then the
number of processors must be = X x Y (that is, x and y multiplied)- in
this case /np 50. (Note: Usually the number of processes is a power of
two. Also, I'll check on why '101' is used and not '100'... I'm following
the model in the zombies property file here...)

This means that a given cell (say, x = -25, y = 37) is on a specific
processor depending on where it is on the processor Cartesian grid;
RepastHPC handles this automatically. When agents move around on the grid
they will move from processor to processor- also handled automatically.

Generally your program should _not_ try to determine which process is
controlling a given patch; the code should be written to manage whatever
agents or patches are present, and otherwise rely on RepastHPC to manage
what is going on under the hood.

I am not sure whether indexing or iterating through an agent set is
faster; under the hood an agent set is a vector, and iterators are more
customarily used, but in terms of absolute performance, I don't know if
there is an argument for one over the other. My hunch is that the iterator
is slightly faster, but I haven't checked. A 'const' iterator may be able
to be optimized by the compiler in ways that a normal one can't, and this
can help.

Best,
John

-- 
John T. Murphy
Computational Postdoctoral Fellow
Decision and Information Sciences and
Argonne Leadership Computing Facility
Argonne National Laboratory
jtm...@an...

On 7/26/11 8:09 AM, "Kashif Zia" <ka...@pe...> wrote:

>John,
>
>What I mean by precompiled is the exe file in "example_bin" of the
>distribution. And the other one is my compilation with VS. It means that
>if
>those programs were running then there must be something wrong with system
>specifications of mine. Most probably that is related with number of
>processors available. However this is only valid for zombie not for
>rumor. 
>
>I am trying to get into rumor model now. Need some time. But what I have
>seen there is that "probably" the graph network is explicitly distributed
>between the processors and managed later on. Zombie is grid based and I
>have
>seen no explicit assignment of cells to a particular processor.
>
>Shortly I will send you the traces of the zombie model.
>
>Agentset iteration problem is solved. One question though: I have used
>index
>(someTurtles [i]) to get all agents in a for loop. I think it is working.
>Is
>there any performance issue comparing it with iterator mechanism?
>
>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...
>
>
>-----Original Message-----
>From: Murphy, John T. [mailto:jtm...@an...]
>Sent: Tuesday, July 26, 2011 2:48 PM
>To: rep...@li...
>Subject: Re: [Repast-interest] Extending Patch class in Repast HPC
>
>Kashif,
>
>At this point we have tried a number of variations and revisions, and it's
>no longer clear to me which error goes with which problem (or even with
>which model- the Zombies model or your new model) and under what
>conditions each error occurs. I've lost track. The error that you are
>getting for your 'simple_following_model' occurs during setup, but the
>error that you were getting for the Zombies model occurs during a 'moveTo'
>operation. They may have the same root cause, but for now let's work on
>just one of them. I recommend the Zombies model first, because I have all
>the code for it already.
>
>If you send me the full output you are getting when you run the Zombies
>model, and the command line and the properties file that you use when you
>get that specific error, I'm sure we can figure it out. Also, I'm not sure
>what you mean by 'the compiled form' vs. 'when you compiled it using VS';
>do you have two different systems that you are using it on, and if so what
>are they?
>
>Best,
>John
>
>-- 
>John T. Murphy
>Computational Postdoctoral Fellow
>Decision and Information Sciences and
>Argonne Leadership Computing Facility
>Argonne National Laboratory
>jtm...@an...
>
>
>
>
>On 7/26/11 3:29 AM, "Kashif Zia" <ka...@pe...> wrote:
>
>>Hello John
>>
>>I ran rumor model both in compiled form and when I compiled it using VS.
>>It
>>running perfect. For zombie_model, even the compiled example (with given
>>props files) is giving the same access violation error.
>>
>>So it can be concluded that there is some problem with parallelism in
>>zombie
>>model when it is running on my system. I do not know what?
>>
>>With 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...
>>
>>
>>-----Original Message-----
>>From: Murphy, John T. [mailto:jtm...@an...]
>>Sent: Tuesday, July 26, 2011 3:30 AM
>>To: rep...@li...
>>Subject: Re: [Repast-interest] Extending Patch class in Repast HPC
>>
>>Kashif,
>>
>>You should be able to run with the /np 4 switch even on a machine with
>>only
>>two processors; the additional processes are run as separate threads. It
>>won't be as fast as on a machine with 4 independent processors, but it
>>should run.
>>
>>That said, the proc.per.x and proc.per.y properties in the Zombies model
>>have to match the number of processes when they are multiplied, not
>>added.
>>The properties indicate the number of processes in the 'x' and 'y'
>>directions in the model's space; 2 x 2 = 4, 2 x 4 = 8, etc., are valid,
>>but
>>the last settings you say you used, proc.per.x = 1, proc.per.y = 1, /np 2
>>are not. 
>>
>>I'll have to check on the error tomorrow. There is no actual error shown
>>in
>>the text you sent. Could you re-send? Or you can wait until your cluster
>>is
>>installed and try again then.
>>
>>Best,
>>John
>>
>>John T. Murphy, PhD, M.A. Ed.
>>Computational Postdoctoral Fellow
>>Argonne National Laboratory
>>jtm...@an...
>>________________________________________
>>From: Kashif Zia [ka...@pe...]
>>Sent: Monday, July 25, 2011 7:49 AM
>>To: Murphy, John T.; rep...@li...
>>Subject: RE: [Repast-interest] Extending Patch class in Repast HPC
>>
>>Hello John
>>
>>My error remains there.
>>
>>About number of processors, it seems to be reason. Unfortunately I only
>>can
>>use my own system with 2 processors right now. With switch np = 4, the
>>following error is generated:
>>
>>>       
>>>simple_following_model.exe!std::vector<double,std::allocator<double>
>>>::size()  Line 879 + 0x6 bytes C++
>>        
>>simple_following_model.exe!std::vector<double,std::allocator<double>
>>>::operator[](unsigned int _Pos=0)  Line 914 + 0x8 bytes        C++
>>
>>simple_following_model.exe!repast::Point<double>::operator[](unsigned int
>>index=0)  Line 206      C++
>>        simple_following_model.exe!repast::relogo::RelogoAgent::xCor()
>>Line
>>51 + 0xd bytes  C++
>>        simple_following_model.exe!InitializeTarget::operator()(AmI *
>>device=0x02544e00)  Line 25 + 0x8 bytes C++
>>
>>simple_following_model.exe!repast::relogo::AgentSet<AmI>::apply<Initializ
>>e
>>Ta
>>rget>(const InitializeTarget & func={...})  Line 412 + 0x13 bytes
>>C++
>>        simple_following_model.exe!FollowingObserver::initializeAmIDir()
>>Line 56 + 0x34 bytes    C++
>>
>>simple_following_model.exe!FollowingObserver::setup(repast::Properties
>>props={...})  Line 92   C++
>>
>>simple_following_model.exe!repast::relogo::SimulationRunner::run<Followin
>>g
>>Ob
>>server,patchExt>(repast::Properties & props={...})  Line 117    C++
>>
>>simple_following_model.exe!runFollowing(std::basic_string<char,std::char_
>>t
>>ra
>>its<char>,std::allocator<char> > propsFile="zombie.props")  Line 35
>>C++
>>        simple_following_model.exe!main(int argc=3, char * *
>>argv=0x009860b8)  Line 55 + 0x1f bytes  C++
>>        simple_following_model.exe!__tmainCRTStartup()  Line 555 + 0x19
>>bytes   C
>>        simple_following_model.exe!mainCRTStartup()  Line 371   C
>>        kernel32.dll!7c817077()
>>        [Frames below may be incorrect and/or missing, no symbols loaded
>>for
>>kernel32.dll]
>>
>>simple_following_model.exe!std::_Vector_const_iterator<std::_Vector_val<A
>>m
>>I
>>*,std::allocator<AmI *> > >::_Compat(const
>>std::_Vector_const_iterator<std::_Vector_val<AmI *,std::allocator<AmI *>
>>> >
>>& _Right=...)  Line 241 + 0x2 bytes     C++
>>
>>
>>I also tried it with /np 2 changing the 'proc.per.x = 1' and 'proc.per.y
>>=
>>1'. But it does not work.
>>
>>Our cluster facility is getting ready; installation etc. As soon as I get
>>it
>>running on that facility, I will let you know.
>>
>>Thanks for consistent support.
>>
>>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...
>>-------------------------------------------------------------------------
>>-
>>--
>>--
>>Magic Quadrant for Content-Aware Data Loss Prevention
>>Research study explores the data loss prevention market. Includes
>>in-depth
>>analysis on the changes within the DLP market, and the criteria used to
>>evaluate the strengths and weaknesses of these DLP solutions.
>>http://www.accelacomm.com/jaw/sfnl/114/51385063/
>>_______________________________________________
>>Repast-interest mailing list
>>Rep...@li...
>>https://lists.sourceforge.net/lists/listinfo/repast-interest
>>
>>
>
>
>--------------------------------------------------------------------------
>--
>--
>Magic Quadrant for Content-Aware Data Loss Prevention
>Research study explores the data loss prevention market. Includes in-depth
>analysis on the changes within the DLP market, and the criteria used to
>evaluate the strengths and weaknesses of these DLP solutions.
>http://www.accelacomm.com/jaw/sfnl/114/51385063/
>_______________________________________________
>Repast-interest mailing list
>Rep...@li...
>https://lists.sourceforge.net/lists/listinfo/repast-interest
>
>

Re: [Repast-interest] Extending Patch class in Repast HPC

The Repast Suite is a family of free agent-based modeling libraries.

Re: [Repast-interest] Extending Patch class in Repast HPC