distaix issueshttps://git.rwth-aachen.de/acs/public/simulation/DistAIXFramework/distaix/-/issues2022-04-25T15:56:01+02:00https://git.rwth-aachen.de/acs/public/simulation/DistAIXFramework/distaix/-/issues/5Handling of unexpected behavior2022-04-25T15:56:01+02:00Stefan DählingHandling of unexpected behaviorCurrently agents assume an ideal communication with other agents. This has to be extended such that agents can handle unexpected situations e.g., messages get lost, an agent replies with an unexpected message, an agent does not reply wit...Currently agents assume an ideal communication with other agents. This has to be extended such that agents can handle unexpected situations e.g., messages get lost, an agent replies with an unexpected message, an agent does not reply within a certain amount of time...https://git.rwth-aachen.de/acs/public/simulation/DistAIXFramework/distaix/-/issues/6Improve profile reading and storing2022-04-25T15:54:22+02:00Sonja HappImprove profile reading and storingAt the moment, profiles are read by collective MPI IO operations and stored in each process. This can be improved by parallelizing the reading of all profile files and storing the data in a shared memory section on each computing node. T...At the moment, profiles are read by collective MPI IO operations and stored in each process. This can be improved by parallelizing the reading of all profile files and storing the data in a shared memory section on each computing node. The steps to take are the following:
- create a split MPI communicator for each node
- allocate one shared memory segment per profile on each node
- make sure that each profile file is read by only one process in the split MPI communicator
- store profile content to respective shared memory segment
- make sure that the FBScomponents library reads correctly from the shared memory segments
This method should no longer require collective MPI IO operations to read the profile files and reduce the required memory for profile storing.https://git.rwth-aachen.de/acs/public/simulation/DistAIXFramework/distaix/-/issues/7Improve scenario file reading and storing2022-04-25T15:54:38+02:00Sonja HappImprove scenario file reading and storingCurrently all processes read and store the scenario files `component.csv` and `el_grid.csv`. This duplicates data in memory, since the same files are available in each process. Especially for large scenarios, this becomes convenient.
Th...Currently all processes read and store the scenario files `component.csv` and `el_grid.csv`. This duplicates data in memory, since the same files are available in each process. Especially for large scenarios, this becomes convenient.
The scenario files could be read by only one process and stored into an MPI shared memory section accessible by all processes on one computing node.https://git.rwth-aachen.de/acs/public/simulation/DistAIXFramework/distaix/-/issues/9Code refactoring for behaviors2022-06-01T15:49:52+02:00Sonja HappCode refactoring for behaviorsThe code structure of agent behaviors is currently a little messed up.
- An agent behavior always requires a logic function `execute_agent_behavior()` that defines what the agent does in every simulation time step based on knowledge and ...The code structure of agent behaviors is currently a little messed up.
- An agent behavior always requires a logic function `execute_agent_behavior()` that defines what the agent does in every simulation time step based on knowledge and incoming messages of other agents that have been received via MPI (Message Routers).
- An agent behavior can OPTIONALLY use an instance of `villas_interface` to exchange data with external systems. This interface also requires a logic defining the interface initialization and its behavior in each simulation time step
We need to refactor the code structure so that it is clear where agent behavior logic and where agent VILLAS interface logic are implemented. It should be possible to use one VILLAS interface logic with multiple agent behavior logics and vice versa. Code duplication should be avoided as much as possible.
My first idea is separating the interface init + logic from the behaviors and moving it to separate classes that can be used by agent behaviors and are optionally called during agent behavior logic init and during `execute_agent_behavior()`.https://git.rwth-aachen.de/acs/public/simulation/DistAIXFramework/distaix/-/issues/11CI: Create unit tests for VILLASnode interface2022-06-01T14:41:45+02:00Sonja HappCI: Create unit tests for VILLASnode interfaceWe should come up with some simple unit tests for the VILLASinterface class for the supported node types mqtt and nanomessage to ease the debugging.
For example, a ping pong between two agents could work to test basic functionality.We should come up with some simple unit tests for the VILLASinterface class for the supported node types mqtt and nanomessage to ease the debugging.
For example, a ping pong between two agents could work to test basic functionality.https://git.rwth-aachen.de/acs/public/simulation/DistAIXFramework/distaix/-/issues/14Allow configuration of simulation start time in model.props file2022-04-25T15:57:26+02:00Sonja HappAllow configuration of simulation start time in model.props fileSee !11See !11Felix WegeFelix Wegehttps://git.rwth-aachen.de/acs/public/simulation/DistAIXFramework/distaix/-/issues/15Use C++ interface of VILLASnode2022-06-01T15:49:52+02:00Sonja HappUse C++ interface of VILLASnodeWe should switch to the C++ interface of VILLASnode in the `VILLASinterface` class to be compatible with the latest and coming versions of VILLASnode. This entails significant changes in the `VILLASinterface` class.
First and foremost, ...We should switch to the C++ interface of VILLASnode in the `VILLASinterface` class to be compatible with the latest and coming versions of VILLASnode. This entails significant changes in the `VILLASinterface` class.
First and foremost, we have use the "parse" functions of VILLASnode to set the config params of each node. Until now, we access and set these params manually. This is no longer possible because now they are "hidden" behind protected or private members of the VILLASnode `Node` class.
I suggest to move the configuration params for the `VILLASinterface` from the model.props to a separate json file (and specify the json file as config property in the model.props) so that the format of the config is similar to that of VILLASnode. We can read the json file in each process and hand the contents as `json_t` (using libjansson) to the VILLASinterface class.
This approach has one disadvantage: We would need to configure the signals (signal names, types, units) in the json file as well because they have to be known for the parsing process. This collides with the current approach of the `VILLASmessage` class that is used to derive and define a specific message format for an agent behavior and to facilitate the actual transfer of data between VILLASnode and DistAIX. We need to rethink this approach in order to avoid duplication of code and signal definitions.
If have started the work here 390dab5d.
Comments are welcome @felix.wege