Hi Gaby,

I would still encourage you to write this as an extension. It sounds like a
pretty typical use case for extensions in NetLogo, though obviously it's
completely up to you. Instead of implementing the preprocessing of the
position data and calling out to AMPL API in the main method of your Java
program, you would do it from the body of the implementation of the
primitive. There's a few things that make an extension easier:

- Running from the main NetLogo program gives you the visualization,
development, and inspection capabilities of NetLogo, making it much easier
to write, debug, and understand the behavior of the model.
- Calling out to NetLogo with the controlling API is possible, but a pain
to work with frankly. Figuring out how to retrieve the correct information
from NetLogo is hard, and getting information back into NetLogo is even
harder (or rather, doing it in a way that doesn't introduce bizarre, hard
to find bugs). It likely requires the parent program to be written
specifically for the given model. In an extension, you get all this for
free; the model decides what information to pass to the extension, when to
get the results, and what to do with them.
- In general, using the controlling API means that you have to write a lot
of code to do things that NetLogo normally does for you.

> The challenge is that I want the Netlogo simulation to keep running while
the ILP optimization is being executed.

This may be a challenge, but implementing as an extension or with the
controlling API doesn't make much difference for this. An easy way to do
this in the extension is to write two primitives, `ipl:run-optimization`
and `ipl:get-results` (assuming the name of your extension is `ipl`).
`ipl:run-optimization` takes in the positional data as an argument,
preprocesses the data and calls out to AMPL API. The call to AMPL API
should either happen in a separate thread or with an asynchronous API
method if AMPL API has one. This asynchronous would have to happen whether
you're writing an extension or using the controlling API. You would then
run `ipl:get-results` when the model needs the results. This primitive
should report the optimized positional information. (Note, if you go this
route, make sure the right turtle is getting the right positional result)

> Also, I want the ILP optimization to be triggered several times during
one simulation (each time for a different group of turtle).

For an extension, this is quite easy. You simply call the primitives
multiple times with different data. For the controlling API, it's more
difficult, your main program has to manually find the turtles in each group
(that is, you kind of need to re-implement NetLogo's `with` primitive).

If you post the Java code that preprocesses the data and calls out to AMPL
API with placeholder variables for the positional information, I'd be happy
to show how to write the corresponding extension primitives. I'm also happy
to offer advice on the controlling API route as well, but probably won't be
able to be as helpful since it's more complicated and freeform.

Hope that helps!
Bryan


On Tue, Feb 12, 2019 at 4:20 PM Gaby Joe Hannoun <gabyjoe.hann...@gmail.com>
wrote:

>
> Hello,
>
> Thank you for your reply.
> Based on the documentation provided about Netlogo extensions, I am not
> sure if building a Netlogo extension is actually the solution in my case.
>
> I lean towards using the controlling API. I will do my best to explain the
> model below:
>
> I want a java main class to activate my Netlogo simulation in which the
> turtles will start moving in random directions. At a defined point in time,
> I want the positions of the turtles retrieved from Netlogo and reported to
> java. These positions are to be preprocessed in the java main class. Then,
> the processed data will be sent to an AMPL model to execute an ILP
> optimization using CPLEX (AMPL API used). After the ILP optimization is
> complete, a final position (goal generated by the ILP) is disseminated back
> to the each turtle in Netlogo (Each turtle will now adjust its movement and
> go to that specific position).
>
> The challenge is that I want the Netlogo simulation to keep running while
> the ILP optimization is being executed. Also, I want the ILP optimization
> to be triggered several times during one simulation (each time for a
> different group of turtle).
>
> I hope it is clear.
>
> Thank you in advance.
>
> Gaby
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Tuesday, 22 January 2019 14:13:31 UTC-5, Bryan Head wrote:
>>
>> Hi Gaby,
>>
>> There are two options I see for this. The first, and probably simplest,
>> is to wrap the ILP optimization library in a NetLogo extension. For
>> instance, the matrix extension wraps the JAMA java library:
>> https://github.com/NetLogo/Matrix-Extension (though it's a little on the
>> old side). A simpler example, if you're comfortable with Scala, is the CSV
>> extension, which wraps the Apache Commons CSV library:
>> https://github.com/NetLogo/CSV-Extension. The basic workflow is that you
>> would add a reporter primitive to your extension that takes as an argument
>> the necessary data for ILP and then returns the output of the optimization.
>>
>> The other option would the controlling API, which allows NetLogo to be
>> used as a library in another Java program:
>> https://github.com/NetLogo/NetLogo/wiki/Controlling-API.
>>
>> This sounds like a perfect case for an extension, so I would recommend
>> that approach over the controlling API approach.
>>
>> Hope that helps!
>> Bryan
>>
>> On Tue, Jan 22, 2019 at 7:09 AM <gabyjoe...@gmail.com> wrote:
>>
>>> Hello,
>>>
>>> I would like to use Netlogo in combination with a Java code that run an
>>> ILP optimization.
>>> During the simulation, input data (for the optimization) is required
>>> from Netlogo and the output of the optimization is to be disseminated back
>>> to Netlogo.
>>>
>>> I am not sure if it is possible to invoke and control the NetLogo
>>> application from the Java program (in which the optimization takes place)
>>> while maintaining the flow of data between NetLogo and java, or if there is
>>> a more practical technique to do that.
>>>
>>> Thanks,
>>> Gaby
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "netlogo-devel" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to netlogo-deve...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>> --
>> Bryan Head
>> PhD Candidate, Computer Science
>> Center for Connected Learning and Computer-Based Modeling
>> Department of Electrical Engineering and Computer Science
>> Northwestern University
>>
> --
> You received this message because you are subscribed to the Google Groups
> "netlogo-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to netlogo-devel+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Bryan Head
PhD Candidate, Computer Science
Center for Connected Learning and Computer-Based Modeling
Department of Electrical Engineering and Computer Science
Northwestern University

-- 
You received this message because you are subscribed to the Google Groups 
"netlogo-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to netlogo-devel+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to