distaix issueshttps://git.rwth-aachen.de/acs/public/simulation/DistAIXFramework/distaix/-/issues2022-06-01T14:42:46+02:00https://git.rwth-aachen.de/acs/public/simulation/DistAIXFramework/distaix/-/issues/1Create second scalability factor column in components.csv file2022-06-01T14:42:46+02:00Sonja HappCreate second scalability factor column in components.csv fileCurrently the scalability of the warm water profiles (thermal demand) is read as the last parameter of a subtype if this line in the agent_creator method (Model) is not commented. A second column containing the scaling factor of the seco...Currently the scalability of the warm water profiles (thermal demand) is read as the last parameter of a subtype if this line in the agent_creator method (Model) is not commented. A second column containing the scaling factor of the second profile should be added to the subtypes in the components.csv file. This affects also the https://git.rwth-aachen.de/acs/research/swarmgrid/scenariogenerator project as the column containing S_r will be shifted to the right by one column through this.https://git.rwth-aachen.de/acs/public/simulation/DistAIXFramework/distaix/-/issues/2Integrate Nanomsg support in Villas_interface class2019-02-19T20:13:27+01:00Sonja HappIntegrate Nanomsg support in Villas_interface classFelix WegeFelix Wegehttps://git.rwth-aachen.de/acs/public/simulation/DistAIXFramework/distaix/-/issues/3Add parameter for ICT connectivity2021-08-18T09:26:43+02:00Sonja HappAdd parameter for ICT connectivityIt is possible to determine whether a node of the electrical grid is connected to an ICT system or not. Such a parameter should be integrated in DistAIX to test scenarios in which only a subset of all agents participated in an approach.It is possible to determine whether a node of the electrical grid is connected to an ICT system or not. Such a parameter should be integrated in DistAIX to test scenarios in which only a subset of all agents participated in an approach.Sonja HappSonja Happhttps://git.rwth-aachen.de/acs/public/simulation/DistAIXFramework/distaix/-/issues/4Ensure behavior: check state of MQTT connection before proceding with handsha...2019-10-30T15:00:54+01:00Sonja HappEnsure behavior: check state of MQTT connection before proceding with handshake in behavior initThis method would replace the hard coded waiting time in the Ensure behavior init method.This method would replace the hard coded waiting time in the Ensure behavior init method.Sonja HappSonja Happhttps://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/8Create documentation of components.csv and el_grid.csv2020-10-06T11:09:05+02:00Felix WegeCreate documentation of components.csv and el_grid.csvCurrently there is no comprehensive documentation of the available components, cables and their parameters.
Such a documentation could help to understand and/or create scenarios.
Include as `/doc/scenarios.md` or similar.Currently there is no comprehensive documentation of the available components, cables and their parameters.
Such a documentation could help to understand and/or create scenarios.
Include as `/doc/scenarios.md` or similar.Felix WegeFelix Wegehttps://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/10Code refactoring for model.cpp2020-11-17T12:16:37+01:00Sonja HappCode refactoring for model.cppThe model.ccp file contains 1500+ lines of code. To improve readability and the code structure we should refactor the code and separate the following functions:
- [x] FBS functions: `model_fbs.cpp` already there
- [x] Config functions: ...The model.ccp file contains 1500+ lines of code. To improve readability and the code structure we should refactor the code and separate the following functions:
- [x] FBS functions: `model_fbs.cpp` already there
- [x] Config functions: `model_config.cpp` anything for reading files and parameters = anything that happens in constructor + reading profiles (should happen in constructor as well...)
- [x] Init functions for networks: `model_init_networks.cpp` anything called in `Model::init()` that creates and initializes el. or communication networks
- [x] Init functions for agents: `model_init_agents.cpp` anythin called in ``Model::init()` that created and initializes agents and their behaviorsSonja HappSonja Happhttps://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/12Boost: fix deprecated headers progress.hpp and timer.hpp2022-05-31T15:58:18+02:00Sonja HappBoost: fix deprecated headers progress.hpp and timer.hppThe following deprecated boost headers are used by DistAIX
`boost/progress.hpp`
`boost/timer.hpp`
They should be replaced by the facilities provided in
`boost/timer/timer.hpp` and/ or
`boost/timer/progress_display.hpp`The following deprecated boost headers are used by DistAIX
`boost/progress.hpp`
`boost/timer.hpp`
They should be replaced by the facilities provided in
`boost/timer/timer.hpp` and/ or
`boost/timer/progress_display.hpp`Sonja HappSonja Happhttps://git.rwth-aachen.de/acs/public/simulation/DistAIXFramework/distaix/-/issues/13Check topology of scenario at startup2022-01-24T14:39:18+01:00Sonja HappCheck topology of scenario at startupWe should add a check of the scenario's topology at the startup to avoid longish debugging if a simulation fails at the start for no obvious reasons. Main criteria for a correct topology
- no circles
- from root to leaves the IDs of node...We should add a check of the scenario's topology at the startup to avoid longish debugging if a simulation fails at the start for no obvious reasons. Main criteria for a correct topology
- no circles
- from root to leaves the IDs of nodes and transformers have to increase
Possible error detection criterion: A node/ transformer has more than one neighbour with an ID that is smaller than its own ID.Felix WegeFelix Wegehttps://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