vadere issueshttps://gitlab.lrz.de/vadere/vadere/-/issues2023-05-17T16:59:49+02:00https://gitlab.lrz.de/vadere/vadere/-/issues/11Teleporter-Potentialfeld hat falsche Position2023-05-17T16:59:49+02:00Zoennchen, BenediktTeleporter-Potentialfeld hat falsche PositionVon @dietrich vor etwa 3 Jahren hinzugefügt.
Kommentar von @dietrich: Einfacher Ring-test (rimea 4 mit breite 0.1m) zeigt, dass Peds zu spät teleportiert werden / zu früh das Potential eines vorangehenden Peds spüren.Von @dietrich vor etwa 3 Jahren hinzugefügt.
Kommentar von @dietrich: Einfacher Ring-test (rimea 4 mit breite 0.1m) zeigt, dass Peds zu spät teleportiert werden / zu früh das Potential eines vorangehenden Peds spüren.https://gitlab.lrz.de/vadere/vadere/-/issues/20JSON save to file and load from file should remember last location2023-05-17T16:56:41+02:00Ghost UserJSON save to file and load from file should remember last locationIt would be great, if the JFileChooser dialogs in the GUI's tabs "Simulation", "Model", "Pedestrians", and "Topography" would remember their last location.
Common use case: Load a generated test topography from a separate file in a dire...It would be great, if the JFileChooser dialogs in the GUI's tabs "Simulation", "Model", "Pedestrians", and "Topography" would remember their last location.
Common use case: Load a generated test topography from a separate file in a directory other than the project directory.
Save and Load dialogs of one tab should maybe share one location. Dialogs from different tabs should probably not share the same location, since they are for different "file types".
Default can be the project directory. Or store it in something like an ini file to restore it in the next session.https://gitlab.lrz.de/vadere/vadere/-/issues/27Ugly classes JsonConverter & StateJsonConverter2023-05-17T16:56:19+02:00Zoennchen, BenediktUgly classes JsonConverter & StateJsonConverterJsonConverter and StateJsonConverter contain only static methods which is not OO. The code could be more elegant. Refactoring required.JsonConverter and StateJsonConverter contain only static methods which is not OO. The code could be more elegant. Refactoring required.https://gitlab.lrz.de/vadere/vadere/-/issues/69In simulator, create packages for (mandatory) "main models" and (optional) "s...2023-05-17T16:52:51+02:00Ghost UserIn simulator, create packages for (mandatory) "main models" and (optional) "sub models"A simulation requires a "main model" (e.g., OSM) and has optional sub models (e.g., a group model). This should also be reflected on package level.
**But watch out:** this change would break current simulator code (because package names...A simulation requires a "main model" (e.g., OSM) and has optional sub models (e.g., a group model). This should also be reflected on package level.
**But watch out:** this change would break current simulator code (because package names are hard-coded in source code somewhere). Therefore, extend VADERE migration assistant.https://gitlab.lrz.de/vadere/vadere/-/issues/108NelderMead - Toleranz als Attribut herausziehen2023-05-17T16:49:30+02:00Schuhbaeck, StefanNelderMead - Toleranz als Attribut herausziehenhttps://gitlab.lrz.de/vadere/vadere/blob/develop/VadereSimulator/src/org/vadere/simulator/models/osm/optimization/StepCircleOptimizerNelderMead.java#L66
The tolerance of the solver might need to be even smaller to avoid all overlaps. Un...https://gitlab.lrz.de/vadere/vadere/blob/develop/VadereSimulator/src/org/vadere/simulator/models/osm/optimization/StepCircleOptimizerNelderMead.java#L66
The tolerance of the solver might need to be even smaller to avoid all overlaps. Unless they're only related with the pedestrians which are considered for the calculation. xref #90.https://gitlab.lrz.de/vadere/vadere/-/issues/127Testsuite TestOSM - Add processors and checks2023-05-17T16:39:10+02:00Marion GoedelTestsuite TestOSM - Add processors and checksAt the moment, the only check in the Continuous Integration setup is if the scenarios are simulated within a limited time. In addition, plausible checks - either provided by the RIMEA Guidelines or by * - should be added for the Continuo...At the moment, the only check in the Continuous Integration setup is if the scenarios are simulated within a limited time. In addition, plausible checks - either provided by the RIMEA Guidelines or by * - should be added for the Continuous Integration setup. That means, the relevant output processors need to be added and their outputs need to be compared to thresholds within the Python CI setup.
Compare Issue #111
@BZoennchen Already added several Test Processors to check the outputs.
Missing:
* [ ] rimea_10_pathfinding (Test Processor that checks if the pedestrians went to the right target is necessary)
* [ ] corner_waiting_time_processor_test
* [ ] narrow_passage
* [ ] rimea4
* [ ] rimea5 (spawning needs to be adapted)
* [ ] rimea8
* [ ] rimea11 - rimea14https://gitlab.lrz.de/vadere/vadere/-/issues/131Scenario is valid but output files are moved to 'corrupted' because trajector...2023-05-17T16:35:35+02:00Ghost UserScenario is valid but output files are moved to 'corrupted' because trajectory file is missingWhat is the meaning of the "corrupted" folder? I think simulation runs that are valid and all outputs are correctly written out (just without the trajectories file) should not get in this folder. Because the name indicates that something...What is the meaning of the "corrupted" folder? I think simulation runs that are valid and all outputs are correctly written out (just without the trajectories file) should not get in this folder. Because the name indicates that something went wrong with the output.
Reason: in the suq-controller I am generally not interested in the trajectory file and it only generates data.https://gitlab.lrz.de/vadere/vadere/-/issues/137[Discussion] RealRandomSpawn - How often should we try to place the pedestrians?2023-05-17T16:31:58+02:00Marion Goedel[Discussion] RealRandomSpawn - How often should we try to place the pedestrians?The new spawning method in the SingleSourceController divides the space in a grid which leads to certain side effects e.g. pedestrians are only place in the same "rows" and "columns".
@BZoennchen Added a new SourceController (SingleSour...The new spawning method in the SingleSourceController divides the space in a grid which leads to certain side effects e.g. pedestrians are only place in the same "rows" and "columns".
@BZoennchen Added a new SourceController (SingleSourceRealRandomController) which places the pedestrians randomly within the given source shape (at the moment limited to a rectangle). For this method, one needs to check if the next pedestrian position leads to overlapping pedestrians.
##### The question to be discussed is: How many times should we try to place the pedestrians before giving up and what should happen if we give up?
At the moment, we give it 100 tries and then the rest of the pedestrians are generated in the next / following time steps.
Other Possibilites (please feel free to add your ideas):
- Stop the simulation if the source area is too small for the selected number of pedestrians.https://gitlab.lrz.de/vadere/vadere/-/issues/140Scenario Checker - wishlist2023-05-17T17:07:24+02:00Marion GoedelScenario Checker - wishlistSince the topography checker is extended to the other tabs, here is a place to add in your ideas / wishes on what the Scenario Checker could do:
#### Simulation
* [x] ERROR: Bounds for `simTimeStepLength` - Suggestion: [0.01 - 1]
* [...Since the topography checker is extended to the other tabs, here is a place to add in your ideas / wishes on what the Scenario Checker could do:
#### Simulation
* [x] ERROR: Bounds for `simTimeStepLength` - Suggestion: [0.01 - 1]
* [ ] WARNING: realTimeSimRatio != 0 - only if started from console
(Maybe this could also be realized by visualizationEnabled = false -> then automically realTimeSimRatio is set to 0)
#### Model
* [ ] WARNING: OSM + optimizationType = DISCRETE AND varyStepDirection = False -> Background: Pedestrians might not be able to walk through small passages
* [ ] WARNING: `loadingType` "CONSTANT_RESPECT_TARGETS" and "DYNAMIC" because they are deprecated
(compare: https://conwiki1.cc.private.hm.edu/confluence/display/FK07PD/VADERE+Input+Parameters)
* [ ] WARNING if the parameters deviate from the default configuration - to avoid accidental "mis-"settings
* [x] WARNING if groupSizeDistribution of any source is different from [1.0] but AttributesCGM is not present in Model tab (no groups will be simulated)
#### Topography
* [x] WARNING: No target that has `absorbing` = true (that means pedestrians will never leave the simulation)
* [x] WARNING: if a list of targets is defined but one (which is not the last one) has the attribute `absorbing` = true
-> pedestrians won't reach their final target
* [x] WARNING: if `radius` != 0.2 (because at the moment all potentials are calibrated for this radius)
* [x] ERROR: If in a source a group distribution is given where something other then groups of 1 are produced and the group submodel is not given throw an error.
* [ ] ERROR: If a pedestrian has no target (separate pedestrian)
* [ ] ERROR: If distributionParameter of the source is 0.0 - leads to Exception (Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException)
* [ ] WARNING: if the source is too small for the amount of agents spawning. Some formula to estimate the pedestrian density required here, e.g. sourceArea / spawnNumberInSeconds < alpha => warning!
* [ ] WARNING: if `footStepsToStore` is zero (position interpolation and computing speed does not work then properly)
* [ ] WARNING: if `lineCrossProcessor` is within obstacle (flow will not be calculated correctly!)
-> maybe also, `LineCrossProcessor` attribute `Line line` can be defined as `Measurement Area`
* [ ] ERROR: agents might stop suddenly in front of non-absorbing targets if agent's `minStepLength` and target's `deletionDistance` are in conflict. Therefore, check `minStepLength < deletionDistance` or `minStepLength + eps < deletionDistance`. See #140.
* [ ] ERROR: if area of obstacle == 0
* [ ] NO WARNING: check for the targets if they are used by a dynamic element
##### TargetChangers
* [x] NO WARNING: If a ``TargetChanger`` is present, some targets might be used only by it. In this case, a warning is currently displayed that the target is unused.
* [ ] WARNING: If a ``TargetChanger``is present but ``useMinimumStepLength`` is ´´true``. Recommend to set to ´´false´´.
##### Free-flow speed
* [ ] ERROR: In attributesPedestrians: When the `speedDistributionMean` is set larger or smaller than the `minimumSpeed` and `maximumSpeed` (NOTE: same as in Topography checker for single placed peds)
* [ ] ERROR: Negative (maybe even non-positive?) `minimumSpeed` && The `maximumSpeed` set larger than 12 m/s (12.4 m/s is the world record by Usain Bolt) (NOTE: same as in Topography checker for single placed peds)
* [ ] ERROR: `minimumSpeed` is larger than `maximumSpeed`
* [ ] WARNING: If the free-flow std is larger than the limits for `minimumSpeed` and `maximumSpeed` allow.
#### Data processing
* [ ] WARNING if `writeSimulationData` = false even though output processors are added and files are defined in which their output should be saved
* [ ] ERROR if group model is active groupId Processor must be selected
* [ ] ERROR if `PedestrianPositionProcessor` is set and `footStepsToStore` is 0. Bachground: The pedestrian position processor uses the latest foot step for interpolation, so it always needs the latest footstep and therefore a capacity of minimum 1.https://gitlab.lrz.de/vadere/vadere/-/issues/143[GroupModel] (Re-)Calibration of the CentroidGroupModel2023-05-17T16:29:39+02:00Zoennchen, Benedikt[GroupModel] (Re-)Calibration of the CentroidGroupModelIf we combine the CentroidGroupModel with PotentialFieldPedestrianCompactSoftshell and PotentialFieldObstacleCompactSoftshell the CentroidGroupModel produces unrealistic movement patterns in high density situations (see screenshot). In m...If we combine the CentroidGroupModel with PotentialFieldPedestrianCompactSoftshell and PotentialFieldObstacleCompactSoftshell the CentroidGroupModel produces unrealistic movement patterns in high density situations (see screenshot). In my opinion we have to increase "groupMemberRepulsionFactor" : 0.5 since the PedestrianPotential in case of CompactSoftshell is higher than for Compact. If one compares evacuation times there are lower if the group model is active which should not be the case!!
"groupMemberRepulsionFactor" : 0.01 (default)
![failGroups](/uploads/8f3e94048d9e691f97ff86bc651d88bb/failGroups.png)
"groupMemberRepulsionFactor" : 0.5
![GroupSuccess](/uploads/421193d546a2958ae11f122f288c2b04/GroupSuccess.png)https://gitlab.lrz.de/vadere/vadere/-/issues/144The first step on the stairs gives an illegal position on the stairs2023-05-17T16:29:06+02:00Ghost UserThe first step on the stairs gives an illegal position on the stairsThe easiest and straightforward fix is to correct the first step on the stairs. This can be done by projecting the first illegal position onto the first or last tread (depending on where the pedestrian entered the stairs).The easiest and straightforward fix is to correct the first step on the stairs. This can be done by projecting the first illegal position onto the first or last tread (depending on where the pedestrian entered the stairs).https://gitlab.lrz.de/vadere/vadere/-/issues/149Test "TestCLOptimalStepsModel" causes an endless loop and a GPU error2023-05-17T16:27:42+02:00Ghost UserTest "TestCLOptimalStepsModel" causes an endless loop and a GPU errorThis test causes an endless loop and a GPU error so that the operating system does not response properly (even when the corresponding Java process is killed).
Linux' journal reports following:
```
benedikt@R4-015-3-1:~$ journalctl
......This test causes an endless loop and a GPU error so that the operating system does not response properly (even when the corresponding Java process is killed).
Linux' journal reports following:
```
benedikt@R4-015-3-1:~$ journalctl
...
Okt 11 09:49:19 R4-015-3-1 kernel: amdgpu 0000:02:00.0: GPU fault detected: 147 0x09784402
Okt 11 09:49:19 R4-015-3-1 kernel: amdgpu 0000:02:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00369D7D
Okt 11 09:49:19 R4-015-3-1 kernel: amdgpu 0000:02:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0A008002
Okt 11 09:49:19 R4-015-3-1 kernel: amdgpu 0000:02:00.0: VM fault (0x02, vmid 5) at page 3579261, read from 'TC2' (0x54433200) (8)
```Zoennchen, BenediktZoennchen, Benedikthttps://gitlab.lrz.de/vadere/vadere/-/issues/173Possibly redudant JSON Parameters2023-05-17T16:11:22+02:00Marion GoedelPossibly redudant JSON ParametersIn the parameter list of VADERE that we assembled for S2UCRE, and more specifically team HF, we wrote down that the parameter densityDependentSpeed is
> probably a relict from very old times, when we adjusted the speed in dependency of ...In the parameter list of VADERE that we assembled for S2UCRE, and more specifically team HF, we wrote down that the parameter densityDependentSpeed is
> probably a relict from very old times, when we adjusted the speed in dependency of the density. Today we calibrate the personal space and the agents adjust their speeds automatically to preserve their personal space. I would guess that this parameter needs tobe weeded out.
(Compare: https://conwiki1.cc.private.hm.edu/confluence/display/FK07PD/VADERE+Input+Parameters)
We also stated that `digitsPerCoordinate` and `printFPS` are not used.
I suggest to check if the parameters are used in the simulator and if not, remove them in the next version of the JSON.https://gitlab.lrz.de/vadere/vadere/-/issues/179[Readme] How to write new issues2023-05-17T17:08:38+02:00Marion Goedel[Readme] How to write new issues1. **Use templates when creating new issues.**
* The templates contain common questions which are relevant for new issues.
* The templates can be selected from the drop down menu next to the title bar.
![GitLab-TemplatesDropDo...1. **Use templates when creating new issues.**
* The templates contain common questions which are relevant for new issues.
* The templates can be selected from the drop down menu next to the title bar.
![GitLab-TemplatesDropDown](/uploads/7f5b7426b1285692770abe205ade1a3e/GitLab-TemplatesDropDown.png)
2. **Use the [existing labels](https://gitlab.lrz.de/vadere/vadere/labels) and respect their use cases which are described in the label description (at least, use one of the priority labels: ~"High priority", ~"Medium priority" or ~"Low priority").**https://gitlab.lrz.de/vadere/vadere/-/issues/184[Readme] How to work on an issue2023-05-17T17:09:08+02:00Ghost User[Readme] How to work on an issue1. **Assign yourself to the issue** (to show other developers that you are working on this issue).
2. **Assign the label ~"Doing".**
3. **Close the issue if the implementation is finished** (this includes unit tests, documentation and po...1. **Assign yourself to the issue** (to show other developers that you are working on this issue).
2. **Assign the label ~"Doing".**
3. **Close the issue if the implementation is finished** (this includes unit tests, documentation and possible adaptions in [CHANGELOG.md](https://gitlab.lrz.de/vadere/vadere/blob/master/CHANGELOG.md)).
Following figure visualizes this workflow:
![GitLab-Issue-Workflow](/uploads/1bcf8b603d3a23e7ffa8207af8b37b96/GitLab-Issue-Workflow.png)https://gitlab.lrz.de/vadere/vadere/-/issues/187[Readme] How to contribute code2023-05-17T15:57:20+02:00Ghost User[Readme] How to contribute code**The aim is to always maintain a working `master` branch. "Working" means that all tests in the continuous integration (CI) pass.**
The tests do not guarantee a bug-free state, but everything that is tested works.
The main reasons to...**The aim is to always maintain a working `master` branch. "Working" means that all tests in the continuous integration (CI) pass.**
The tests do not guarantee a bug-free state, but everything that is tested works.
The main reasons to maintain this state on `master` are:
* "Release quick and often", i.e. whenever required, and without spending weeks of debugging to get the tests running again.
* Isolate bugs faster, which means reduced debug time. When the `master` passes all tests and your new feature does not, you only have to look for the code changes of your new feature, which is a pretty good starting point for debugging.
# Ways to contribute code are:
Optimally, there is already an existing issue that you want to solve. If there is, link the issue in your commit messages (i.e. `#[ISSUE_ID]`) or your merge request description. Gitlab automatically links all commits/merge requests with this issue and it is easier to find issue related code.
## Standard work-flow
* branch from `master` (or any other branch if applicable)
* Make this branch a merge request in gitlab https://gitlab.lrz.de/vadere/vadere/merge_requests .
* When you push to a new branch, gitlab immediately suggests to you to make this branch you pushed at to create a merge request.
* You can create a branch and merge request with one click from an existing issues directly with "Create merge request".
* For an example, there is a merge request attached at the bottom of this issue.
* Optionally, if you intend to work for longer, mark the branch name with "WIP:" (Work in progress), so everyone is aware to not merge until the WIP status is resolved. Gitlab offers a button to add/remove this status.
* Push all new code (refactoring, bugfix or new feature) to this branch.
* After your implementation is complete, wait until the continuous integration passes. You get usually an email if it does not.
* Solve all merge conflicts in your branch/merge request (and **not** on `master`). Gitlab checks for you if there are conflicts in the merge request.
* After your work is done, all potential merge conflicts are resolved and your merge request passes the CI, then you can merge to `master`. Click the option "remove branch", which removes the underlying branch you pushed your code to after successful merge. For a new code contribution you can create a new branch. Note: you may also want to remove the branch locally.
* You can also use the option "Merge when pipeline passes" in your merge request. Then you do not have to wait for the CI.
* Optionally: If there are a lot of commits that were just work in progress for a single issue, you may choose to **squash** the commits when merging, i.e. all commits are grouped into one on `master` which keeps the history clean.
## "Small commits"
If you just commit something you are very sure it doesn't break anything, go ahead and push directly on `master`.
## I wrote a new test that would fail on `master`
The `master` is not bug-free then. But we still need it to pass all tests. There may be other merge requests relying on a working `master`. Therefore, proceed with the standard way: Create a merge request and first fix the bug, then add the test (both in a merge request). The concept is that the `master` always fulfils the **current** set of tests.
# What to do when the `master` fails?
If the CI happens to fail on `master` after you committed/merged new code and it is certain that this the cause, then **undo your commit on master and proceed the standard way** (i.e. create merge request with your commits). Compare your code to the (now running again) master, and look out on what is causing troubles.https://gitlab.lrz.de/vadere/vadere/-/issues/204[Feature] Remove preset for data output in json mode.2023-05-17T15:45:24+02:00Ghost User[Feature] Remove preset for data output in json mode.
https://gitlab.lrz.de/vadere/vadere/blob/master/VadereGui/src/org/vadere/gui/projectview/view/DataProcessingView.java#L141
Remove this json template. New scenarios will always get a default set of processors.
https://gitlab.lrz.de/vadere/vadere/blob/master/VadereGui/src/org/vadere/gui/projectview/view/DataProcessingView.java#L141
Remove this json template. New scenarios will always get a default set of processors.https://gitlab.lrz.de/vadere/vadere/-/issues/236Improve memory efficiency of output processors2023-04-27T16:31:08+02:00Ghost UserImprove memory efficiency of output processors### Problem to solve
Currently, the output processors keep all their data into memory and write everything to disk after the simulation is finished. For larger scenarios, this increases the memory immensely (which lowers the ability for ...### Problem to solve
Currently, the output processors keep all their data into memory and write everything to disk after the simulation is finished. For larger scenarios, this increases the memory immensely (which lowers the ability for parallel computations, e.g. with the suq-controller).
Generally, there are two types of processors:
1. Only require information from the current state
2. Require information from past states (e.g. speed average over the last 5 time steps, or a PCA over the entire data)
The second type is more tricky. In a discussion we agreed to handle the second case as follows:
* Write out the information to a file (**)
* After the simulation is done read the data again and transform it accordingly.
(**) Note: this should be asynchronously to not slow down the simulation too much (this part requires probably more discussion!)
### List of processors that can write data in an online fashion:
####
* AreaDensityCountingProcessor
* AreaDensityVoronoiProcesor
* AreaSpeedProcessor
* BonnMotionTrajectoryProcessor (needs refactoring)
* FundamentalDiagramAProcessor
* FundamentalDiagramBProcessor
* FundamentalDiagramCProcessor
* FundamentalDiagramDProcessor
* FundamentalDiagramEProcessor
* GroupMemberEuclideanDistance
* GroupMemberPotentialDist
* GroupMemberSeparatedObstacle
* PedestrianDensityCountingProcessor
* PedestrianDensityGaussianProcessor
* PedestrianFlowProcessor
* PedestrianGroupIDProcessor
* PedestrianGroupMaxDistProcessor
* PedestrianGroupSizeProcessor
* PedestrianLineCrossProcessor
* PedestrianOffsetPositionProcessor
* PedestrianOSMStrideLengthProcessor
* PedestrianOverlapProcessor
* PedestrianPositionProcessor
* PedestrianSourceIdProcessor
* PedestrianStartTimeProcessor
* PedestrianStateProcessor
* PedestrianStateProcessor
* PedestrianTargetIdProcessor
* PedestrianVelocityDefaultProcessor
* PointDensityCountingAlgorithm
* PointDensityGaussianAlgorithm
* QueueWidthProcessor
* SumVoronoiAlgorithm
### List of processors that require past data (offline, delayed online, preprocess required)
* EvacuationTimeProcessor
* MaxOverlapProcessor
* MeanPedestrianEvacuationTimeProcessor
* NumberOverlapsProcessor
* PedestrianLastPositionProcessor
* PedestrianTrajectoryProcessor
* PedestrianVelocityByTrajectoryProcessor
* PedestrianVelocityProcessor
### Unknown
* PedestrianBehaviourProcessor
* PedestrianCrossingTimeProcessor
* PedestrianEndTimeProcessor
* PedestrianFootStepProcessor
* PedestrianWaitingEndTimeProcessor
* PedestrianWaitingTimeProcessor
* TargetFloorFieldGridProcessorhttps://gitlab.lrz.de/vadere/vadere/-/issues/237Provide alternative data formats to write out data2023-04-27T16:29:27+02:00Ghost UserProvide alternative data formats to write out data### Problem to solve
Currently, we write out everything in csv/text-based format. However, this requires a lot of memory and is rather slow (for large amounts of data). An often used software is the HDF5 format.
All new data formats s...### Problem to solve
Currently, we write out everything in csv/text-based format. However, this requires a lot of memory and is rather slow (for large amounts of data). An often used software is the HDF5 format.
All new data formats should be optional (the csv should remain the default). First evaluate the architecture how this can be achieved. Also check #236
### Links and references
* https://support.hdfgroup.org/products/java/
* https://stackoverflow.com/questions/9227099/hdf5-in-java-what-are-the-difference-between-the-availabe-apis
* https://wiki-bsse.ethz.ch/display/JHDF5/JHDF5+%28HDF5+for+Java%29https://gitlab.lrz.de/vadere/vadere/-/issues/240Overview: Ideas and collection for refactoring the DataProcessors for online ...2023-04-27T16:29:28+02:00Ghost UserOverview: Ideas and collection for refactoring the DataProcessors for online setting#236 @hm\-schuhba1
This issue only organises the current thought process.
### Requirements
*Note: this is only a collection, not everything has to be implemented*
* What to do with data (from OutputFile / Socket view):
* send c...#236 @hm\-schuhba1
This issue only organises the current thought process.
### Requirements
*Note: this is only a collection, not everything has to be implemented*
* What to do with data (from OutputFile / Socket view):
* send current collected data to File / Socket
* only for Files: preprocess data and transform accordingly (e.g. carry out PCA on data) -- potentially this data can also be send over socket, after the simulation is finished.
* Some processors keep the values in RAM (and do not write the data), online processors only keep the current values in RAM to be accessed by other processors, OfflineProcessors should never provide data to other data (**TODO: check this, if this is true currently!**)
* Online writing should be async, to not slow down too much the simulation
* For performance data could/should be buffered when writing out (e.g. https://docs.oracle.com/javase/7/docs/api/java/io/BufferedWriter.html)
* For sockets there have to be new user settings that need to be integrated somewhere in the GUI (like the file)
### Interface / ABC for all "DataProcessors"
+ init()
### Interface / ABC for all "OnlineDataProcessors"
```
+ close()
+ asyncWrite()
# Only callable when wirting out to files, not to socket, but needs to be implemented by all OnlineDataProcessors
+ readData(OnlineProcessorList) -> Reads the files that were written out during simulation and transforms it accordingly
```
### Interface / ABC for all "OfflineDataProcessors"
```
attr1: List of required OnlineProcessors
+ postprocessWriteData() -> calls "readData" and then transforms the data accordingly
```
### Files to look at in Vadere:
* "OutputFile" --> currently writes data to the file after simulation, the OutputFile would basically be either "Online" or "Offline", depending on the DataProcessor
* An "OutputFile" has either **only** online processors or **only** offline processors (check this, and set an attribute)
* The "OutputFile" should implement a function "asyncWriteFile" that writes the current content of processors during simulation, (only if "OutputFile" contains processors with online ability and therefore themself implement "asyncWrite")
* The "OutputFile" should "readData" and cast it to the values required (**this will be a bit tricky...?**)
* The "OutputFile" should implement a function "postprocessWriteFile" that handles the computation to the processors "postprocessWriteData()"
* "ProcessorManager" --> via method "writeOutput" each OutputFile is triggered to write output.
* "Simulation" --> in the `finally` block the output is written after the simulation, for the online property it should be somewhere in the loop, for offline property it should be called at the same position.
### New classes / User interface
For Sockets a new class "OutputSocket" could be implemented which only allows "OnlineDataProcessors"
![image](/uploads/d673727f35a759bc4d3cb5136580103b/image.png)