2
$\begingroup$

I work with scientific simulation, but what I like the most in programming is creating graphical user interfaces and 2D or 3D outputs to visualize the evolution of the simulations. I know most input data in scientific simulation are in text files, not in GUIs, and that more usually statistical graphs are scientifically more relevant than 3D movies. But I still can't accept I have to give up on my esteem for GUIs and 3D in science...

Do you think I should adopt the model-view-controller paradigm in my programs? Can I separate high-performance calculation from visualization using multithread, such that crashes in visualization don't affect the calculations? And sucht that I can switch from text input files to GUIs and back again to my whim. Which software do you recommend?

$\endgroup$

2 Answers 2

3
$\begingroup$

This answer is my personal opinion. I believe that high performance numerical solvers are not a good place to use MVC pattern. Additional layers and specific data flow will not help to get a better performance. MVC and MVVM (Model-View-ViewModel) are commonly used for GUI developing. If you want to develop pre/post processor where performance is not such important thing, architectural patterns can help you organize a project and make it easier to develop (especially if you work in a team). I believe that GUI for numerical software should be always separated from computational core. Not only by using multi-threading, but it should be located in a separate program. That kind of architecture is commonly found in many commercial numerical softwares like Abaqus or Ansys. If GUI crashes it will not to affect calculations. Solver can run separately on HPC machine where graphical interface is not available. Moreover, GUI can be written using almost any language which provide suitable sets of widgets - Java, C#, or C++ (QT). It depends on target platform and your skills in programming. You can even use some general purpose post/pre processors like GMSH, Paraview or GiD and combine it with your solver. High performance numerical solvers are almost always written in some low level languages like C, C++, Fortran which do not support MVC/MVVM patterns in the same way how Java or C# does.

In case of my PHD thesis I decided to write my own preprocessor using C# and MVVM pattern and separated numerical solver using C++ which consumes input file generated by preprocessor. Such architecture was easier to develop and maintain.

$\endgroup$
2
$\begingroup$

Whilst the MVC/MMVM patterns can be useful where appropriate, I would avoid trying to shoehorn the numerics into a pattern led by your chosen GUI (or other UI) framework. Unless you multi-thread in some fashion, the GUI itself will be unresponsive as the simulation progresses until its completion.

You mention that you wish to view the simulation's evolution as time progresses: for this you could use synchronous callbacks from the numerical code, or if implementing in a separate process you could monitor the standard output (stdout) from the solver if that provides any useful "tick" data. This may involve a non-trivial amount of development work compared to a simple batch solver process.

Visual excellence (GUIs, 3D, etc) also do not have to be mutually exclusive with batch solution processes. A number of simulations I performed (coupled FEM-Neural) reported relative complex in-progress data to text terminals and post-processed more detailed visual output.

$\endgroup$
1
  • $\begingroup$ Unless you multi-thread in some fashion, the GUI itself will be unresponsive as the simulation progresses until its completion, I bitterly discovered that after spending a lot of time building the GUI of a curve fitting program I made (I couldn't use commercial ones because of an integral in the expression that I had to calculate numerically). $\endgroup$ Commented Jan 3, 2016 at 3:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.