ACS issueshttps://git.rwth-aachen.de/groups/acs/-/issues2022-06-01T15:49:52+02:00https://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/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/scenariogenerator/-/issues/1Add -merge-nodes option2021-08-03T15:09:42+02:00Stefan DählingAdd -merge-nodes optionThe -merge-nodes option allows to combine two scenarios. The components of both scenarios connected to nodes with the same id are merged and connected to the node with the same id in the target scenario. This way two scenarios with the s...The -merge-nodes option allows to combine two scenarios. The components of both scenarios connected to nodes with the same id are merged and connected to the node with the same id in the target scenario. This way two scenarios with the same topology can be merged, meaning that the target scenario has the same topology and comprises the components of both scenarios.Stefan DählingStefan Dählinghttps://git.rwth-aachen.de/acs/public/virtualization/cricket/-/issues/19CPU: Infiniband support2020-10-21T14:36:30+02:00Niklas Eilingniklas.eiling@eonerc.rwth-aachen.deCPU: Infiniband supportData transfers should support infiniband verbs as transport
Maybe use clnt_raw from tirpc?
Else we have to replace/modify tirpc in case infiniband is used.Data transfers should support infiniband verbs as transport
Maybe use clnt_raw from tirpc?
Else we have to replace/modify tirpc in case infiniband is used.https://git.rwth-aachen.de/acs/public/virtualization/cricket/-/issues/18CPU: Shared Memory for Containers2022-08-02T11:16:30+02:00Niklas Eilingniklas.eiling@eonerc.rwth-aachen.deCPU: Shared Memory for ContainersWe can have shared memory between hosts and containers. The memory transfers can thus be made fasterWe can have shared memory between hosts and containers. The memory transfers can thus be made fasterhttps://git.rwth-aachen.de/acs/public/ontology/sargon/-/issues/2Inconsistencies between files2020-03-17T15:21:34+01:00Markus MirzInconsistencies between filesHello everyone,
I've stumbled upon some inconsistencies. E.g. sometimes it's "soported" Network in the LD files instead of "supportedNetwork".
The example sensor uses "adress" instead of "locatedAt".
The generic device example is missi...Hello everyone,
I've stumbled upon some inconsistencies. E.g. sometimes it's "soported" Network in the LD files instead of "supportedNetwork".
The example sensor uses "adress" instead of "locatedAt".
The generic device example is missing mandatory Attributes / Properties.
Will post further updates.Markus MirzMarkus Mirzhttps://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/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/ontology/sargon/-/issues/1split repo2020-03-16T12:12:01+01:00Markus Mirzsplit repoHi,
would it be possible to split the repo into "device wizard" and "datamodel specification"? Otherwise i cannot restructurethe git efficiently.
Please. check on this.Hi,
would it be possible to split the repo into "device wizard" and "datamodel specification"? Otherwise i cannot restructurethe git efficiently.
Please. check on this.Markus MirzMarkus Mirz2020-01-15https://git.rwth-aachen.de/acs/public/teaching/gi4/gi4/-/issues/3Projects for KGÜ Assignments2022-04-08T11:51:48+02:00Martin Kröningmartin.kroening@eonerc.rwth-aachen.deProjects for KGÜ AssignmentsIt would be very useful to be able to work on KGÜ Assignments from a starter project, instead of having to copy from the PDF and reformat them.
I just created [mkroening/gi4_kguebung05](https://git.rwth-aachen.de/mkroening/gi4_kguebung0...It would be very useful to be able to work on KGÜ Assignments from a starter project, instead of having to copy from the PDF and reformat them.
I just created [mkroening/gi4_kguebung05](https://git.rwth-aachen.de/mkroening/gi4_kguebung05) as I faced this problem.
Note that some of my changes are more than just cosmetic.
I think having such projects in the [gi4](https://git.rwth-aachen.de/gi4) group would be good.
@stvogel, what do you think?https://git.rwth-aachen.de/acs/public/virtualization/cricket/-/issues/17Add binary to ckp_dir2020-03-18T09:25:27+01:00Jonathan KlimtAdd binary to ckp_dirWe could store the binary in the checkpoint directory. This would make it easier to store the checkpoint as a whole thing.We could store the binary in the checkpoint directory. This would make it easier to store the checkpoint as a whole thing.https://git.rwth-aachen.de/acs/public/virtualization/cricket/-/issues/16Why do the programs detach from the kernel2019-05-17T15:10:01+02:00Jonathan KlimtWhy do the programs detach from the kernelI think it is bad practice for such a program to detach itself. The same can be achieved by using `&` in the shell and it makes it hard (impossible) to use return codes.I think it is bad practice for such a program to detach itself. The same can be achieved by using `&` in the shell and it makes it hard (impossible) to use return codes.https://git.rwth-aachen.de/acs/public/teaching/gi4/gi4/-/issues/2Provide full Dockerfile2019-05-16T09:49:14+02:00Steffen Vogelstvogel@eonerc.rwth-aachen.deProvide full Dockerfile@slankes Can you add the full Dockerfile for `rwthos/gi4` to this repo?
I can also do it myself. But I could not find it :(@slankes Can you add the full Dockerfile for `rwthos/gi4` to this repo?
I can also do it myself. But I could not find it :(Stefan Lankesslankes@eonerc.rwth-aachen.deStefan Lankesslankes@eonerc.rwth-aachen.dehttps://git.rwth-aachen.de/acs/public/virtualization/cricket/-/issues/15Checkpoint/Restore process randomly fails sometimes2020-03-18T09:24:17+01:00Niklas Eilingniklas.eiling@eonerc.rwth-aachen.deCheckpoint/Restore process randomly fails sometimesrequires further investigationsrequires further investigationshttps://git.rwth-aachen.de/acs/public/virtualization/cricket/-/issues/14Refactor main.c2019-04-30T15:13:26+02:00Jonathan KlimtRefactor main.cIt's a huge (huuuuge) mess in a sense of: It is hugeIt's a huge (huuuuge) mess in a sense of: It is hugeJonathan KlimtJonathan Klimthttps://git.rwth-aachen.de/acs/public/virtualization/cricket/-/issues/13support multi-GPU setups2022-08-02T11:16:19+02:00Niklas Eilingniklas.eiling@eonerc.rwth-aachen.desupport multi-GPU setupshttps://git.rwth-aachen.de/acs/public/virtualization/cricket/-/issues/12do not hardcode checkpoint location2019-05-28T14:27:21+02:00Niklas Eilingniklas.eiling@eonerc.rwth-aachen.dedo not hardcode checkpoint locationin [cricket_restore](src/main.c#L190) and [cricket_checkpoint](src/main.c#L874) the path for the checkpoint file are hardcoded. This should really be a paramter.
Related to #11in [cricket_restore](src/main.c#L190) and [cricket_checkpoint](src/main.c#L874) the path for the checkpoint file are hardcoded. This should really be a paramter.
Related to #11Jonathan KlimtJonathan Klimthttps://git.rwth-aachen.de/acs/public/virtualization/cricket/-/issues/11Argument Parser2019-05-10T11:44:41+02:00Jonathan KlimtArgument ParserHaving a *real* argument parser would be nice....
Related: #12 #9 Having a *real* argument parser would be nice....
Related: #12 #9 Jonathan KlimtJonathan Klimthttps://git.rwth-aachen.de/acs/public/virtualization/cricket/-/issues/10Split main.c into different units2019-05-28T14:27:20+02:00Jonathan KlimtSplit main.c into different unitsespecially `cricket_restore` has ~680 lines and should be splitted into smaller chuncksespecially `cricket_restore` has ~680 lines and should be splitted into smaller chuncksJonathan KlimtJonathan Klimthttps://git.rwth-aachen.de/acs/public/virtualization/cricket/-/issues/9make cricket start not only accept fully qualified paths2019-08-27T10:10:55+02:00Niklas Eilingniklas.eiling@eonerc.rwth-aachen.demake cricket start not only accept fully qualified paths`cricket start` benötigt aktuell einen fully qualified path als Parameter. Relative Pfade und Pfade mit Variabeln (zB `~`) werden noch nicht unterstützt.`cricket start` benötigt aktuell einen fully qualified path als Parameter. Relative Pfade und Pfade mit Variabeln (zB `~`) werden noch nicht unterstützt.