You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While we tried to stick to our plan as best as we could, we decided to do some things a little different.
13
+
The biggest difference being a Client-Server approach although we explicitly mentioned we would not realize this.
14
+
The original triggering point for this were all kinds of loading times and issues with concurrency:
15
+
for any GUI application, one of the key features is its responsiveness to user input. Be it numerical input or just clicking and moving things around - the GUI should react as fast as possible.
16
+
Integrating a GUI directly into the solver application while maintaining this responsiveness meant that the GUI and every other task the actual solver does, need to be separated in different threads
17
+
to assure that the GUI thread has always time for the user.
18
18
19
-
Tab number two handles the the connection to thhe server. The properties for interacting with the server are getting set here.
20
-
Furthermore, the connection can also be disconnected here.
19
+
We started off with this directly integrated and threaded approach and quickly realized that handling correct communication between two or more asynchronous running threads was getting closer and closer to just having two separate applications communicating over an API.
20
+
Knowing that this approach meant we would have to invest a lot more effort and work overtime, we decided on taking this path nontheless as it would come with a lot of other benefits as well.
21
+
Now, using the Server-Client model we have a GUI that can just send commands to the server without needing to wait for a response (most of the time, unless you're specifically asking for data such as water/bathymetry data).
It can also be used in scenarios when using a more powerful machine (e.g. HPC-Cluster) without display access. Just start the program as a server on the remote machine and control it from home via laptop - its that easy.
23
24
24
-
On the next page the user can find all options of configuration for the simulation. The simulation parameters like cell amount, size and offset can be set here.
25
-
In Addition to that, compiler and run time options can be found here. These contain differetn modes, compiler options, flags and usage choices.
26
-
After selecting the simulation has to be recompiled with the according button below.
The last tab contains further actions to interact with the simulation. First, the simulation can be started or killed here.
31
-
Also files for the bathymetry and displacement can be chosen. As an addition, the user can get data like the heigth from the simulation.
33
+
The first thing we did was to modularize our main ``tsunami_lab`` program. The original ``main.cpp`` had one main function that executed the whole program loop.
32
34
33
35
*********************
34
-
Server-side
36
+
Build process
35
37
*********************
36
38
37
39
*********************
38
40
Libraries
39
41
*********************
40
42
43
+
To keep the main code clean, we decided to export most of the code associated with communication to external libraries:
0 commit comments