From: North, M. <no...@an...> - 2010-06-28 18:38:19
|
Tony, Of course, this all depends on the circumstances. I just wanted to be sure everyone interested in this topic knows about the options. Mike ________________________________ From: Bigbee, Tony [mailto:ab...@mi...] Sent: Monday, June 28, 2010 1:32 PM To: rep...@li... Subject: Re: [Repast-interest] 'Communication' between Repast and other software This is an interesting capability, thanks for posting. It looks nice for shared parameters/settings at startup. If Brad's need is to exchange information every time step rather than once per run, however, file i/o is likely to be at least 2 orders of magnitude slower. Perhaps not a big deal for only a few time steps, but for thousands of time steps+ and/or repeated runs, it may matter. Since the C program would also have to implement file reading, parsing, and possibly threading-threading because you'd have to check periodically for the presence of a new file or an existing file was completely written (has a terminator) -it would be more complex than JNI (for small numbers of variables/methods/functions) for per time step to enable data exchange. If the C program spends a lot of time computing results between time steps, however, then the performance of file i/o becomes less of an issue. From: North, Michael [mailto:no...@an...] Sent: Friday, June 25, 2010 5:22 PM To: Bigbee, Tony; bra...@gm...; rep...@li... Subject: RE: [Repast-interest] 'Communication' between Repast and other software Thank you for using Repast! The attached paper discusses another possible means for working with your external program. This approach may not be quite as fast as the options described below, but since it uses simple files, it may be easier to implement. Mike ________________________________ From: Bigbee, Tony [mailto:ab...@mi...] Sent: Friday, June 25, 2010 3:33 PM To: bra...@gm...; rep...@li... Subject: Re: [Repast-interest] 'Communication' between Repast and other software There are several general means of doing interprocess communication, but what you want to do is not trivial for at least a couple of them. Determining how synchronous the C code/model and your Repast/Java code are would be a first step-it sounds like every time step they would exchange information? TCP/IP sockets is one way to do it, but requires development with sockets and possibly threads. Threads are to be avoided if at all possible unless you have compelling requirements (perhaps your C code is computationally expensive). Perhaps a less complicated approach is JNI. The JVM would be the single process executing both the Java code and the binary C code, and you'd simply use Java methods to pass information / 'step' the C code and retrieve a result. Something like: 1. Do other work in the Repast model as necessary and use previous C model information (or starting value). 2. received information = Interprocess.updateCModel( supplied information); //steps the C model where Interprocess is just a class you write that is responsible for communicating with the C model. If there is just a simple numeric variable that the C model is providing to the Java/Repast model and vice versa, this is the simplest approach. You'd likely want a shared configuration/parameter file read by both the Java and C code so they each had starting values with which to work. You might be able to use SWIG to generate the .h files and method signatures for JNI and avoid hand-coding, but I've only used it to generate Python wrappers to C code. For just a single JNI call, SWIG is overkill. The other requirement would be to add the executable 'library' to the load library path when invoking your Repast model (as one of the parameters like classpath). You can read up on JNI here: http://java.sun.com/developer/onlineTraining/Programming/JDCBook/jni.html http://www.swig.org/ You might also be able to used named pipes on a *nix system. There are other ways, but none likely to be as fast. From: Guangyu Zou [mailto:zg...@ho...] Sent: Friday, June 25, 2010 1:40 PM To: bra...@gm...; rep...@li... Subject: Re: [Repast-interest] 'Communication' between Repast and other software Hi, It looks like communication between two processes. You could reach the goal by socket programming. In the external C programs, you created a thread that is responsible for listen to a specific socket. In your Repast program, you could send message to that specific socket when you need to exchange information between them. I am not sure if Repast itself has some special mechanism to implement this. Guangyu > Date: Fri, 25 Jun 2010 10:46:56 -0600 > From: bra...@gm... > To: rep...@li... > Subject: [Repast-interest] 'Communication' between Repast and other software > > Hi, > > I am a new user of Repast, so please forgive me if the answer to my > question is obvious. > > I have created an external program in C that simulates how some > quantity X behaves over time. > > I am interested in building an agent-based model in Repast that > 'communicates' with this external program at every 'tick'. > > That is, at every 'tick' the agent-based simulation in Repast would > received information from the external program, potentially altering > some agent's behavior, and the agent(s) would pass information to the > external program, potentially altering X over time. > > Is this possible? Any ideas as to how this might be done? > > Thank you for your help and advice. > > Cheers, > Brad > > ------------------------------------------------------------------------------ > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > _______________________________________________ > Repast-interest mailing list > Rep...@li... > https://lists.sourceforge.net/lists/listinfo/repast-interest ________________________________ The New Busy think 9 to 5 is a cute idea. Combine multiple calendars with Hotmail. Get busy.<http://www.windowslive.com/campaign/thenewbusy?tile=multicalendar&ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_5> |