search

OFFIS-DAI / Mango.jl

Modular Julia-based agent framework to implement multi-agent systems
https://offis-dai.github.io/Mango.jl/stable/
MIT License
6 stars 0 forks source link

Make `Mango.jl` extend the API of `Agents.jl`? #56

Open Tortar opened 3 weeks ago

Tortar commented 3 weeks ago

Making Mango.jla sort of extension of Agents.jl could make the package a bit more intuitive for people already using Agents.jl and at the same time it could be then possible to use from Mango.jl functionalities which could be already present in Agents.jl e.g. I saw that your @agent macro is very similar to what is already available in Agents.jl, taking the example from https://offis-dai.github.io/Mango.jl/stable/agent/ it could be roughly rewritten as

@agent struct MyAgent(MangoAgent)
    my_own_field::String
end

# internally in Mango.jl
using Agents
export MangoAgent
@agent struct MangoAgent(NoSpaceAgent)
    # default fields of MangoAgent
end

in general, what do you think about this suggestion? Is this even sensible? I see that this would require a major rewriting of the package anyway so I just want to know what are your feelings about this :-)

Notice that we have some precedence: https://github.com/mastrof/MicrobeAgents.jl

rcschrg commented 3 weeks ago

Hello Tortar,

thank you for your suggestion! :) I think it is an interesting idea, especially as we touch Agents.jl way of a) (as you said) building agent structs, and b) with some of our own functionalities in the simulation container, which could be used for a (really simple) agent-based modeling simulation. However, I can also think of difficulties, first, with communication between agents, we really focus on a different aspect of agent systems, the framework Mango.jl shall also bridge the gap between pure scientific simulation and real industry-driven field tests, which would need to run distributed. The core of which makes Mango.jl suitable for our purposes (communication protocols, containering mechanism, convenient APIs for communicating and integration of communication simulation) is really different.

But I can see significant advantages extending Agents.jl with our communication capabilities, or vice-versa Mango.jl with the (agent and world) modeling abilities of Agents.jl. I see a development track for Mango.jl, which could include the integration of Agents.jl, and in fact, we are interested in the broader topic of agent-based modeling. We would need to check in detail where the difficulties lay. I feel it could be possible to partly provide it as an extension, which can use some of Agents.jl functionalities.

I will look into the possibility to migrate parts of Mango.jl to the Agents.jl API, and I will look into the possibility to use parts of Agents.jl modeling capabilities in our simulation container, as I do not think that both packages are compatible when thinking of our real time container, in which actual protocols and actual communication is happening. Optimally, this would result in a) the possibility to use (parts of) Agents.jl within Mango.jl simulations, and b) use (parts of) Mango.jl Agents within a Agents.jl simulation (the latter might be tough though).

Tortar commented 2 weeks ago

This is great!

I'm not sure that these kind of abstraction are suitable but we have at https://juliadynamics.github.io/Agents.jl/stable/devdocs/ some hints on how one could extend the model and space api. I saw that you implemented some new types implementing topologies, at a glance it seems maybe possible to impleement them using a GraphSpace in Agents.jl