EmbeddedMontiArc issueshttps://git.rwth-aachen.de/groups/monticore/EmbeddedMontiArc/-/issues2023-02-12T17:37:21+01:00https://git.rwth-aachen.de/monticore/EmbeddedMontiArc/generators/EMADL2CPP/-/issues/107Naming conventions for emadl network components2023-02-12T17:37:21+01:00Feras MulhemNaming conventions for emadl network components**Current situation**
- A [naming convention](https://git.rwth-aachen.de/monticore/EmbeddedMontiArc/generators/EMADL2CPP/-/blob/master/src/main/java/de/monticore/mlpipelines/workflow/AbstractWorkflow.java#L67) is followed to resolve conf...**Current situation**
- A [naming convention](https://git.rwth-aachen.de/monticore/EmbeddedMontiArc/generators/EMADL2CPP/-/blob/master/src/main/java/de/monticore/mlpipelines/workflow/AbstractWorkflow.java#L67) is followed to resolve configuration such that these are assumed to have the _full name_ of a to-be-trained neural network.
**Tasks**
- [ ] Adjust the naming conventions to exclude the _package name_ from the network full name
- [ ] Adjust the names of the corresponding configurations accordingly. The configurations need also to have package information explicitly ( i.e. _package MyPackage_)https://git.rwth-aachen.de/monticore/EmbeddedMontiArc/simulators/server/-/issues/3Navigation for multiple cars fails2019-10-09T12:55:41+02:00Evgeny KusmenkoNavigation for multiple cars failsPlease debug navigationPlease debug navigationWei XuWei Xu2018-08-15https://git.rwth-aachen.de/monticore/EmbeddedMontiArc/simulators/server/-/issues/4Navigations error in multi-vehicles scenario2018-12-05T15:41:44+01:00Wei XuNavigations error in multi-vehicles scenarioFor single-vehicle scenario, the navigation of car can work correctly.<br>
For multi-vehicles scenario, the navigation of cars can not work correctly. The cars drive irregularly and out of the (road)path. <br>Attach is an error example, ...For single-vehicle scenario, the navigation of car can work correctly.<br>
For multi-vehicles scenario, the navigation of cars can not work correctly. The cars drive irregularly and out of the (road)path. <br>Attach is an error example, which shows a simple 2-vehicles scenario, and the cars should drive in opposite directions, but irregularly. <br>
[vehicle_1]<br>
![vehicle_1](/uploads/fa5afa32672e3746b031b7a513500edd/vehicle_1.jpg)
[vehicle_2]<br>
![vehicle_2](/uploads/b5c72ceafc28029bd9708bf942b2b6b7/vehicle_2.jpg)
Attempting solution: debug the pathfinding algorithm in the multi-vehicles situation.<br>Wei XuWei Xu2018-08-15https://git.rwth-aachen.de/monticore/EmbeddedMontiArc/generators/EMADL2CPP/-/issues/122Network Tagging is ignored (PyTorch Backend)2024-02-05T12:17:01+01:00Jonas DjurevciNetwork Tagging is ignored (PyTorch Backend)# Problem
Multiple instances of the same network are trained separately instead of only once, even though a tagging file is present. While the tagging file is parsed and used to download the dataset, it is not used to determine, which ne...# Problem
Multiple instances of the same network are trained separately instead of only once, even though a tagging file is present. While the tagging file is parsed and used to download the dataset, it is not used to determine, which network instances have to be trained (see method `de.monticore.mlpipelines.workflow.AbstractWorkflow.getNetworkInstanceConfigs`). This requires the provision of one training and one pipeline configuration file per network instance.
# Steps to reproduce
Note: Getting far enough to trigger this problem requires implementing the workaround presented in issue #123, given that it is not yet solved.
Execute the EMADL2CPP generator on the MNISTCalculator example application located in `src/main/resources/calculator_experiment`.
For this purpose, use the following Run Configuration:
- Main class: `de.monticore.lang.monticar.emadl.generator.MontiAnnaCli`
- Program arguments: `-m src/main/resources/calculator_experiment/emadl -r calculator.Connector -o target -b PYTORCH`Antonio AntovskiAntonio Antovskihttps://git.rwth-aachen.de/monticore/EmbeddedMontiArc/simulators/server/-/issues/29New Code2019-10-09T10:50:29+02:00Sabrina WolffNew CodeScreenshots for presentationScreenshots for presentationSecond SprintSabrina WolffMarkus HorlemannUta SkorzinskiSabrina Wolffhttps://git.rwth-aachen.de/monticore/EmbeddedMontiArc/generators/EMAM2Middleware/-/issues/12New EMA Version2019-01-21T13:33:28+01:00Alexander David HellwigNew EMA VersionAlso check other projectsAlso check other projectsAlexander David HellwigAlexander David Hellwighttps://git.rwth-aachen.de/monticore/EmbeddedMontiArc/generators/EMAM2Cpp/-/issues/3No boolen constants available2020-07-02T19:29:49+02:00Malte HeithoffNo boolen constants availableIn an "implementation Math" block you cannot write:
portA = true;
Only
portA = 1;
works.In an "implementation Math" block you cannot write:
portA = true;
Only
portA = 1;
works.Sascha Niklas SchneidersSascha Niklas Schneidershttps://git.rwth-aachen.de/monticore/EmbeddedMontiArc/languages/EmbeddedMontiArc/-/issues/3No Instance Symbol for Constant Ports2018-07-30T19:14:57+02:00Alexander David HellwigNo Instance Symbol for Constant PortsThere is no Instance Symbol that represents Contant Ports.
In my opinion there are two solutions:
1. Change the ``EMAPortInstanceSymbol``(currently always returns ``false`` for ``isConstant()``)
2. Create a ``EMAConstantPortInstanceSymbo...There is no Instance Symbol that represents Contant Ports.
In my opinion there are two solutions:
1. Change the ``EMAPortInstanceSymbol``(currently always returns ``false`` for ``isConstant()``)
2. Create a ``EMAConstantPortInstanceSymbol`` extending ``EMAPortInstanceSymbol``https://git.rwth-aachen.de/monticore/EmbeddedMontiArc/simulators/server/-/issues/25Not Able to Build Project after Changes2019-06-02T01:27:17+02:00ulfetNot Able to Build Project after ChangesGreetings Mr. Kusmenko,
After (I believe) the changes that are made to Maven dependency nexus,
we are not able to run commands such as "mvn install", as it produces messages along the lines:
`Could not resolve dependencies for project...Greetings Mr. Kusmenko,
After (I believe) the changes that are made to Maven dependency nexus,
we are not able to run commands such as "mvn install", as it produces messages along the lines:
`Could not resolve dependencies for project montisim:server:jar:1.0.7: The following artifacts could not be resolved: de.se_rwth.commons:se-commons-logging:jar:1.7.8, montisim:commons:jar:1.0.6, montisim-controller:library:jar:1.0.1, montisim-controller:control:jar:1.0.1, montisim-controller:navigation:jar:1.0.1, montisim-simulation:environment:jar:1.0.7, montisim-simulation:vehicle:jar:1.0.7, montisim-simulation:sensors:jar:1.0.7, montisim-simulation:network:jar:1.0.7, montisim-simulation:simulator:jar:1.0.7, montisim:rmi-model-server:jar:1.1.0, montisim:example-autopilot-ema:jar:0.0.5, de.monticore.lang.montisim:SimLang:jar:1.0.1, de.monticore.lang.montisim:Util:jar:1.0.1, de.monticore.lang.montisim:Weather:jar:1.0.1: Failure to find de.se_rwth.commons:se-commons-logging:jar:1.7.8 in http://repository.jboss.org/nexus/content/groups/public/ was cached in the local repository, resolution will not be reattempted until the update interval of jboss-public-repository has elapsed or updates are forced`
I was trying to create subprojects for server, yet I have seen this problem, and stalled my progress, as I cannot double check if I am doing it right or not.
(assigning issue to your account too to notify you)Evgeny KusmenkoulfetEvgeny Kusmenkohttps://git.rwth-aachen.de/monticore/EmbeddedMontiArc/generators/EMADL2CPP/-/issues/22NullPointerException instead of proper error message when undefined port is used2021-02-03T18:46:34+01:00Andreas WahlenNullPointerException instead of proper error message when undefined port is usedWhen using an undefined port (e.g. in a connect statement) the maven plugin will output a NullPointerException instead of a proper error message.When using an undefined port (e.g. in a connect statement) the maven plugin will output a NullPointerException instead of a proper error message.Evgeny KusmenkoEvgeny Kusmenkohttps://git.rwth-aachen.de/monticore/EmbeddedMontiArc/generators/EMADL2CPP/-/issues/62Object diagrams for model transformations Architecture2023-01-07T12:43:09+01:00Evgeny KusmenkoObject diagrams for model transformations ArchitecturePlease create object diagrams representing the AST/symbol table of a network architecture for several steps of each architecture search algorithm you implementPlease create object diagrams representing the AST/symbol table of a network architecture for several steps of each architecture search algorithm you implementTobias HörnschemeyerNazish QamarTobias Hörnschemeyer2022-12-13https://git.rwth-aachen.de/monticore/EmbeddedMontiArc/generators/EMADL2CPP/-/issues/63Object diagrams for model transformations Configuration2023-03-04T11:01:11+01:00Evgeny KusmenkoObject diagrams for model transformations ConfigurationPlease create object diagrams representing the AST/symbol table of the configuration for several steps of each hyperparameter search algorithm you implementPlease create object diagrams representing the AST/symbol table of the configuration for several steps of each hyperparameter search algorithm you implementHiroshi HamanoAkashKumarDSHiroshi Hamano2023-02-28https://git.rwth-aachen.de/monticore/EmbeddedMontiArc/simulators/simulation/-/issues/29OpenGL visualization2021-10-20T17:38:41+02:00Jean MeuriceOpenGL visualization## Problem
- Right now, the 2D visualization of the maps and vehicles uses the `Graphics2D` java class inside the `Swing` components.
- This is not a very efficient rendering method, especially for large scale cities.
- It is also not p...## Problem
- Right now, the 2D visualization of the maps and vehicles uses the `Graphics2D` java class inside the `Swing` components.
- This is not a very efficient rendering method, especially for large scale cities.
- It is also not precise: the polygon geometry can only be passed with integer pixel positions.
## Solution
Use OpenGL rendering.
- As OpenGL library (for example): [JOGL](https://jogamp.org/jogl/www/)
- [JOGL in Swing](https://www.tutorialspoint.com/jogl/jogl_canvas_with_swing.htm) (Still up-to-date ?)
- [OpenGL 4 JOGL sample](https://github.com/jvm-graphics-labs/hello-triangle)
- TODOs:
- Test a simple 2D triangle with a basic shader.
- Make it build and run using the JOGL maven artifacts.
- Make a *colored triangle* shader with an orthogonal view matrix, test binding it to the map controls (position, zoom). Render a simple triangle (or 2)
- Make a *colored line* shader, same view matrix, test a simple outline.
- Generate the building geometry in one VBO/VAO/EBO set.
- Use the already split convex parts
- The *convex* polygon parts can be rendered using the `GL_TRIANGLE_FAN` drawing mode
- In combination with the [Primitive Restart](https://stackoverflow.com/questions/4386861/opengl-jogl-multiple-triangle-fans-in-a-vertex-array)
- Use an Element-Buffer
- Use the `PRIMITIVE_RESTART` index to separate triangle fans for different polygons
- Since we only want to draw contiguous vertices, the `glMultiDrawElements()` method can be useful
- Generate the road geometry (or visualization lines)
- Generate the vehicle geometry (one VBO/EBO/VAO set)
- Same triangle shader, but give it a view+model matrix (pre-multiplied)
- All the debug lines/elements (AABB, building outlines, ...) can be in their own VBO/EBO/VAO.
- **Check the thread interaction between Swing and OpenGL**. The OpenGL calls are not thread-safe for a given context. Be sure that the OpenGL calls happen in the correct thread.
- [Swing Threads](http://www.javapractices.com/topic/TopicAction.do?Id=153)
**Note**: The existing visualization already "pre-generates" the geometry in some way to save computation. Changing to save this geometry in OpenGL buffer would not be a big change.https://git.rwth-aachen.de/monticore/EmbeddedMontiArc/simulators/basic-simulator/-/issues/5OpenGL visualization2021-10-20T17:38:42+02:00Jean MeuriceOpenGL visualization## Problem
- Right now, the 2D visualization of the maps and vehicles uses the `Graphics2D` java class inside the `Swing` components.
- This is not a very efficient rendering method, especially for large scale cities.
- It is also not p...## Problem
- Right now, the 2D visualization of the maps and vehicles uses the `Graphics2D` java class inside the `Swing` components.
- This is not a very efficient rendering method, especially for large scale cities.
- It is also not precise: the polygon geometry can only be passed with integer pixel positions.
## Solution
Use OpenGL rendering.
- As OpenGL library (for example): [JOGL](https://jogamp.org/jogl/www/)
- [JOGL in Swing](https://www.tutorialspoint.com/jogl/jogl_canvas_with_swing.htm) (Still up-to-date ?)
- [OpenGL 4 JOGL sample](https://github.com/jvm-graphics-labs/hello-triangle)
- TODOs:
- Test a simple 2D triangle with a basic shader.
- Make it build and run using the JOGL maven artifacts.
- Make a *colored triangle* shader with an orthogonal view matrix, test binding it to the map controls (position, zoom). Render a simple triangle (or 2)
- Make a *colored line* shader, same view matrix, test a simple outline.
- Generate the building geometry in one VBO/VAO/EBO set.
- Use the already split convex parts
- The *convex* polygon parts can be rendered using the `GL_TRIANGLE_FAN` drawing mode
- In combination with the [Primitive Restart](https://stackoverflow.com/questions/4386861/opengl-jogl-multiple-triangle-fans-in-a-vertex-array)
- Use an Element-Buffer
- Use the `PRIMITIVE_RESTART` index to separate triangle fans for different polygons
- Since we only want to draw contiguous vertices, the `glMultiDrawElements()` method can be useful
- Generate the road geometry (or visualization lines)
- Generate the vehicle geometry (one VBO/EBO/VAO set)
- Same triangle shader, but give it a view+model matrix (pre-multiplied)
- All the debug lines/elements (AABB, building outlines, ...) can be in their own VBO/EBO/VAO.
- **Check the thread interaction between Swing and OpenGL**. The OpenGL calls are not thread-safe for a given context. Be sure that the OpenGL calls happen in the correct thread.
- [Swing Threads](http://www.javapractices.com/topic/TopicAction.do?Id=153)
**Note**: The existing visualization already "pre-generates" the geometry in some way to save computation. Changing to save this geometry in OpenGL buffer would not be a big change.https://git.rwth-aachen.de/monticore/EmbeddedMontiArc/generators/EMADL2CPP/-/issues/109Open to-dos MA Mulhem2023-02-12T17:37:21+01:00Feras MulhemOpen to-dos MA MulhemOpen to-dos derived from Mulhem's Master thesis
- #108
- #107
- #106Open to-dos derived from Mulhem's Master thesis
- #108
- #107
- #106aixaiaixaihttps://git.rwth-aachen.de/monticore/EmbeddedMontiArc/generators/emam2mqtt/-/issues/5[Optional]Install MQTT(Windows)2019-05-24T13:42:44+02:00Alexander David Hellwig[Optional]Install MQTT(Windows)Install MQTT on a Windows 10 x64 System and add documentation to README.md(or link to existing)Install MQTT on a Windows 10 x64 System and add documentation to README.md(or link to existing)Georg VinogradovGeorg Vinogradovhttps://git.rwth-aachen.de/monticore/EmbeddedMontiArc/generators/emam2someip/-/issues/5[Optional]Install Some/IP(Windows)2019-05-30T15:39:56+02:00Alexander David Hellwig[Optional]Install Some/IP(Windows)Install Some/IP on a Windows 10 x64 System and add documentation to README.md(or link to existing)Install Some/IP on a Windows 10 x64 System and add documentation to README.md(or link to existing)Markus Georg BendelMarkus Georg Bendelhttps://git.rwth-aachen.de/monticore/EmbeddedMontiArc/generators/EMADL2CPP/-/issues/31Order of input port names2021-12-07T16:21:14+01:00Evgeny KusmenkoOrder of input port namesthere is a bug concerning usage of input port names / layer names. order seems to override namesthere is a bug concerning usage of input port names / layer names. order seems to override namesNils BaumannNils Baumannhttps://git.rwth-aachen.de/monticore/EmbeddedMontiArc/generators/EMADL2CPP/-/issues/26Output ports can not be used for further connects2021-03-14T14:15:44+01:00Andreas WahlenOutput ports can not be used for further connectsWhen using an output port as a source of a connect statement, there will be no error or warning but no corresponding code will be generated.
This should either throw an error or just work. Could be helpful in situations like the followi...When using an output port as a source of a connect statement, there will be no error or warning but no corresponding code will be generated.
This should either throw an error or just work. Could be helpful in situations like the following:
```
package ...;
component Test {
port
in x,
out y,
out z;
instance InstX instX;
instance InstY instY;
connect x -> instX.param;
connect instX.res -> y;
connect y -> instY.param; // this is the problematic line, one could of course also use instX.res again
connect instY.res -> z;
}
```Evgeny KusmenkoEvgeny Kusmenkohttps://git.rwth-aachen.de/monticore/EmbeddedMontiArc/generators/cnnarch2x/-/issues/2Padding type2019-09-26T14:00:01+02:00Evgeny KusmenkoPadding typePadding is defined to be a string in the readme, but is actually a list of ints in the implementation.
both should be possiblePadding is defined to be a string in the readme, but is actually a list of ints in the implementation.
both should be possibleJulian Johannes Steinsberger-DührßenBo PengTim Benjamin SchuppJulian Johannes Steinsberger-Dührßen