[Ros]

Hello everyone,

I wanted to share with you the project we were working on the past few months:
DICE (Dynamic Interface for Computation and Evaluation).

It is an open source framework for simplified creation of user interfaces and utilities in the area of numerical simulations.


A few months ago we started creating a concept which would allow the user, specifically an engineer, to create a GUI for OpenFOAM applications in a very simple manner. The goal was to create a library with components and functions for GUI developement and to streamline the workflow for repeated tasks.
The amount of applications and utlities in OpenFOAM makes it a really hard task because the possibilities for modifications are infinite. After a lot of thrown away concepts we came up with an idea to develop a dynamic GUI. This means the generation of the interface through QML and because we try to keep the bar for programming as low as possible we decided to use python as the core language.

More details can be found here:
http://dicehub.net/introducing-dice/

And the result of our mad ideas is DICE.
Here is a short demo of the current state:
https://www.youtube.com/watch?v=G3xrIksSYNY

At the moment we are polishing the code, fixing some critical bugs and working on the documentation. As soon as we are ready we will upload the code to github and make binaries available for a few linux distributions.
We are also working on some solver apps and loops integration for optimization. Our long-term goal is to implement known optimization tools into DICE, e.g. DAKOTA.


So, why are we posting this right now? Because we developed everything by ourselves and have no idea if it makes any sense. Yes, we actually made the greatest mistake an open source project can make and had no communication with the people we are making it for. And now we are fixing this.

What are your thoughts?
What do you think of the concept?
Do you have any ideas for improvement?
Any feedback is welcome, even the negative one!

Thanks!


http://twitter.com/dice_hub
http://dicehub.net

[philippose]

Hi there,
I like the nice clean looking interface, and the way the different features have (can be) integrated into the GUI :-)

It does look a little like the Ansys Workbench :-) But then, to tell you the truth, I was actually thinking about something on those lines too. I found the concept of dragging in modules and connecting them to one another a very interesting idea, and I think it renders itself well to coupling of multiple codes in a clean way.

Of course, the whole idea depends entirely on the modularity of the "DICEengine", and the way the adding on of new codes, solvers, and GUI components have been conceptualised.

Are you guys working with the concept of QT Plugins? Or something more on the lines of what ParaView does?

On the whole, a very very interesting project, and I am definitely very interested in it.... theoretically speaking, also from the development side, simply because I have been thinking about such modular GUI concepts for a long time :-)

Have a nice day!

Philippose

[andrjas]

Originally Posted by philippose

I like the nice clean looking interface, and the way the different features have (can be) integrated into the GUI :-)

Thanks, it was our goal to keep the interface as simple as possible. This way it should be possible to learn to use it quite fast.

Originally Posted by philippose

It does look a little like the Ansys Workbench :-) But then, to tell you the truth, I was actually thinking about something on those lines too. I found the concept of dragging in modules and connecting them to one another a very interesting idea, and I think it renders itself well to coupling of multiple codes in a clean way.

Yes, we know it could look like Workbench. Though there are other tools using the same concept. The idea came from OpenFOAM being modular itself and the need to connect it with different tools.

Originally Posted by philippose

Of course, the whole idea depends entirely on the modularity of the "DICEengine", and the way the adding on of new codes, solvers, and GUI components have been conceptualised.

I hope we got the level of modularity right. The whole program consists of several modules and each app is also a module, where the logic and the GUI parts are split (into python and QML). Adding new codes is done by implementing an app/module for it, which should be not that hard, I hope ;-)

Originally Posted by philippose

Are you guys working with the concept of QT Plugins? Or something more on the lines of what ParaView does?

Neither nor. We developed some QML components which communicate via a thin Qt/C++ layer with python. Python then calls the OpenFOAM code or whatever you want. Each module is a collection of QML and python code and can be added into DICE without recompilation.

Originally Posted by philippose

On the whole, a very very interesting project, and I am definitely very interested in it.... theoretically speaking, also from the development side, simply because I have been thinking about such modular GUI concepts for a long time :-)

Glad to hear. Maybe we could share our concepts sometime.

[philippose]

Hi again :-)
Thanks for the quick and concise explanation of the methods you have used in Dice. It sounds quite flexible.

Will you be putting it onto Github sometime soon? Or will ironing out of the last few loose ends take a while?

Also, are you using some kind of geometry library for visualising the Geometry (STL, obj, etc...) and OpenFOAM meshes? Or did you write all those from scratch? And the actual visualisation is based on OpenGL on top of QML?

And are you using PySide or PyQT5?

Regards,
Philippose

[hannes]

Dear Andrjas,

this looks like a very interesting project.

If I understand right, the idea is similar to a graphical programming language (like e.g. labview) but with specialized high-level "functions" for CAE tasks?

During the last year I have worked on my own framework for automation of CAE tasks (http://sourceforge.net/projects/insightcae/), also with emphasis on OpenFOAM but also other tools (Code_Aster for instance).

My idea (probably similar to yours) is to create modules for certain analyses. But these modules have a very high level of functionality (this is probably a difference to your concept?). There is e.g. one module for simulating a propeller at some certain operating point and this does meshing, simulating and evaluating. And another module computes the open water curves and uses the first one.

Initially, I also had the idea of providing some kind of graphical editor for connecting the modules. But I have to use the framework already productively and I considered this to be too much work for my purposes.

But maybe there will be a chance to integrate my efforts with dice. I'm looking forward to your first code release.

Regards, Hannes

[Ros]

Originally Posted by philippose

Will you be putting it onto Github sometime soon? Or will ironing out of the last few loose ends take a while?

We would like to do it as fast as possible but it will take approximately 2 to 3 weeks. We are also looking for funding options or sponorship but for now we have to do it in our free time, so you can imagine it takes a while.

Originally Posted by philippose

Also, are you using some kind of geometry library for visualising the Geometry (STL, obj, etc...) and OpenFOAM meshes? Or did you write all those from scratch? And the actual visualisation is based on OpenGL on top of QML?

We are using VTK for the visualization and we have built a QML-VTK-interface. The whole software is rendered by OpenGL because of QML. As far as we know we are one of the first to built a large QML application so there is a lot of things to figure/iron out.

Originally Posted by philippose

And are you using PySide or PyQT5?

Initially we started as a pure C++/QML application because we wanted to use the newest Qt5 version. PySide is Qt4 only and PyQt5 was not up to date at that point afaik.

[andrjas]

Originally Posted by hannes

this looks like a very interesting project.

Thanks. Glad you're interested.

Originally Posted by hannes

If I understand right, the idea is similar to a graphical programming language (like e.g. labview) but with specialized high-level "functions" for CAE tasks?

Yep, you're right ;-)

Originally Posted by hannes

During the last year I have worked on my own framework for automation of CAE tasks (http://sourceforge.net/projects/insightcae/), also with emphasis on OpenFOAM but also other tools (Code_Aster for instance).

My idea (probably similar to yours) is to create modules for certain analyses. But these modules have a very high level of functionality (this is probably a difference to your concept?). There is e.g. one module for simulating a propeller at some certain operating point and this does meshing, simulating and evaluating. And another module computes the open water curves and uses the first one.

We've seen your work (http://www.move-csc.de/nofun2014/tal...gerInsight.pdf) and it looks very promising.

We've thought a lot about the level of functionality and there is simply no "right" answer to this. That's why we wanted to cover all possibilities. At the moment we're adding the lower level components, like meshing or simulating, as single modules which can be connected and grouped (latter not implemented yet). However, high level modules still can be written the same way as the low level component (and probably even simpler because of fewer parameters).

For example, in your case for the propeller you may have some configuration files for the mesher and the solver. These files are then manipulated by the app you'd have to write for DICE. The resulting GUI is then a high level module consisting of a mesher and a solver.

Maybe the explanation is too confusing for now...

Originally Posted by hannes

Initially, I also had the idea of providing some kind of graphical editor for connecting the modules. But I have to use the framework already productively and I considered this to be too much work for my purposes.

We know what you mean. That's exactly why we started creating DICE.

Originally Posted by hannes

But maybe there will be a chance to integrate my efforts with dice. I'm looking forward to your first code release.

That would be great. This is why we are making it open source so people with similar ideas can contribute. Tools like Open CASCADE (which you seem to use in your project) would be a great addition to DICE. Let's stay in touch.

Best regards, Andreas

[chriss85]

This looks very promising, I hope you'll success with your plans.

If this works out I might write some config files for some tools, but I guess this is the easiest part of the development

[francois]

Your project looks awesome !
Thanks for sharing your vision and tools for the community

DICE could be THE tool that was missing for OpenFOAM.
I hope, no, I'm sure that the community will warmly welcome your project and contribute to it.

I wish you the best for this awesome project !

Regards,
François

[wyldckat]

Greetings to all!

@Ros, just my two cents here:

1. Awesome looking project, although I'm not very much in favour of the box-like programming... although I am very familiar with its advantages, as I've seen and used in MATLAB's Simulink. And for new users, this is usually the preferred "programming" style.
2. Python + Qt + VTK... I'm having trouble handling the fact that it will take some weeks until you release it... this is essentially one of the holy grails when in comes to OpenFOAM. When this is finally released, there are several tons of features that people will want to add in. Some that I can think of:
   • Easy integration with PyFoam.
   • Somewhat easy integration with pythonFlu.
   • Integrated IPython shell command line, giving users the ability to use Python scripting and shell scripting in a single interface. This could reduce the dependencies on having to use conventional shell scripting.
   • Easy connection to pythonOCC and a whole array of scientific modules that are available for Python.
   • Porting Discretizer to Python, if it makes sense to do so...
   • Creating a module to hookup directly to enGrid.

Personally I would want to integrate this with a ParaView+VTK+Qt+PyQt software stack, but Qt5 is something that ParaView isn't using yet... which means that I'll have to wait even a while longer...

Best regards,
Bruno

[fra76]

A really promising tool!

As many other people here, I wrote my own OpenFOAM wrapper with some GUI to drive the whole simulation process. Some ideas behind it are common to what DICE does, some others are not.
What I have (Python + qt + vtk by the way) is very specific to one type of application, at least in one part of the process, and I've been considering rewriting it to make it more general and future-proof, but the time is never enough for such a project.

I'm really keen to try out DICE as soon as possible and see if and how it can be adapted to my usual workflow!

Thanks for sharing it,
Francesco

[andrjas]

Originally Posted by chriss85

This looks very promising, I hope you'll success with your plans.

If this works out I might write some config files for some tools, but I guess this is the easiest part of the development

I wouldn't underestimate writing config files. We'll get back to you on this ;-)

Originally Posted by francois

Your project looks awesome !
Thanks for sharing your vision and tools for the community

DICE could be THE tool that was missing for OpenFOAM.
I hope, no, I'm sure that the community will warmly welcome your project and contribute to it.

I wish you the best for this awesome project !

Regards,
François

Thanks for the motivational words. Always welcome!

@wyldckat: Thanks for you input.
To your points: We wanted to see first if there is any interest in our project. Now that we know we'll try to release it as soon as possible. So please be patient.

• PyFoam: we're actually already using a modified parser from it. As for other modules it's possible but we have to see if it makes sense for the concept.
• pythonFlu: Should be usable as any other OpenFOAM tool. Or do you see any tighter integration apart from an IDE?
• IPython: cool idea, may be possible as an own app. Right now we have some apps that simply run python and bash commands (without styling and the fancy stuff)
• pythonOCC: also a great idea! Blender and OpenSCAD could also be an option.
• Discretizer: Not really sure if it really makes sense...
• enGrid: For what purpose? Could you give an example?
• ParaView: right now you can start ParaView and it loads the case. Could you elaborate your use case on this software stack? I don't see any more possiblities than using pvpython for integration.

We're always thinking about integrating such tools into DICE, but for now we have to concentrate on building the basis for the framework.


@fra76:
Thanks for sharing! Did you publish your code or intend to? Especially I'd like to see more Qt-VTK examples, we're having some trouble there right now.

[chriss85]

Originally Posted by andrjas

I wouldn't underestimate writing config files. We'll get back to you on this ;-)

Could you post an example file sometime so we can gain an insight into the format?

[cutter]

Hi,

congratulations, very impressive demo application! A stable and usable (and this case even beautifully loooking) GUI platform might be a major boost for the whole OF ecosystem.

I've already been playing with some helper Qt apps myself (specific to my preprocessing, processing and monitoring). The idea was to integrate them into a larger suite later on. I never got to specify the interfaces or module system though. Your approach based on Python and Qt seems to be very promising. Can't wait to see some code and maybe provide some additions.

Some additional thoughts: Did you already consider the licensing of the application/library?! In my option this should allow both OSS and proprietary extensions, as this the foundadion for platforms like Eclipse, Netbeans, Salome and even Visual Studio. Don't get me wrong: as OF users we're all dedicated to OSS, but a sane compatibility to proprietary components might be essential for the success of the software.

Cutter

[Ros]

Originally Posted by chriss85

Could you post an example file sometime so we can gain an insight into the format?

Actually the config files are the usual OpenFOAM config files. They are copied from the template folder and are then manipulated through python by the GUI. So, you will have to write some python functions with our library. For an example please wait for the release.

Originally Posted by cutter

congratulations, very impressive demo application! A stable and usable (and this case even beautifully loooking) GUI platform might be a major boost for the whole OF ecosystem.

Thanks! For a stable and usable version there is still a long way to go.

Originally Posted by cutter

I've already been playing with some helper Qt apps myself (specific to my preprocessing, processing and monitoring). The idea was to integrate them into a larger suite later on. I never got to specify the interfaces or module system though. Your approach based on Python and Qt seems to be very promising. Can't wait to see some code and maybe provide some additions.

It would be great if you could contribute. But we have to make it clear that Qt apps/widgets are not the same as QML apps. It is not possible to integrate old Qt apps into QML.

Originally Posted by cutter

Some additional thoughts: Did you already consider the licensing of the application/library?! In my option this should allow both OSS and proprietary extensions, as this the foundadion for platforms like Eclipse, Netbeans, Salome and even Visual Studio. Don't get me wrong: as OF users we're all dedicated to OSS, but a sane compatibility to proprietary components might be essential for the success of the software.
Cutter

We thought a lot about the licensing issue and its actually one of the main reasons why we didn't release the code right now. Our current idea is to use GPL licence. As for the proprietary components you can use them as long as they are executables but the binding (python/Qml) needs to stay open source. This should allow writing configuration files which are then run by proprietary components. Do you think it would work? Any advice is welcome!

[wyldckat]

Originally Posted by andrjas

@wyldckat: Thanks for you input.
To your points: We wanted to see first if there is any interest in our project. Now that we know we'll try to release it as soon as possible. So please be patient.

I've gotten use to how fast time flies

Originally Posted by andrjas

• PyFoam: we're actually already using a modified parser from it. As for other modules it's possible but we have to see if it makes sense for the concept.
• pythonFlu: Should be usable as any other OpenFOAM tool. Or do you see any tighter integration apart from an IDE?
• IPython: cool idea, may be possible as an own app. Right now we have some apps that simply run python and bash commands (without styling and the fancy stuff)
• pythonOCC: also a great idea! Blender and OpenSCAD could also be an option.

The idea on these 4 is to keep in mind that the underlying engine (software stack) you're running on is one of the most powerful software development platforms available to the engineering+scientific community. Even more than MATLAB and any other similar software. Python+Qt+VTK open a tremendous world of possibilities! In other words: pure scripting is something that should not be forgotten

Originally Posted by andrjas

• Discretizer: Not really sure if it really makes sense...

The idea would be to re-write or re-imagine parts of Discretizer as new modules in DICE. There is a lot of know-how inside Discretizer's Ruby based code that can come in handy, for not having to re-do the whole creative process.

Originally Posted by andrjas

• enGrid: For what purpose? Could you give an example?

enGrid is currently divided into two major components: main executable and library, all using Qt/C++ and VTK. The separation of GUI from the core meshing technology isn't fully separated yet, but porting the GUI part of enGrid to DICE could make things a bit easier on enGrid's development side, in the sense that enGrid's core programming could focus on meshing, while the GUI could be developed and extended as modules in DICE (i.e. easier contribution development). In addition, the benefit of separation, would be that one feature that people wish for in enGrid is scripting capabilities... now imagine if you could plug modules of geometrical modelling with pythonOCC, directly into the enGrid mesher, using additional parametric components... and drop in Dakota for good measure... it would be limitless!! Oh, and pythonFlu for a dynamic/adaptive simulation solver prototyping...

Originally Posted by andrjas

• ParaView: right now you can start ParaView and it loads the case. Could you elaborate your use case on this software stack? I don't see any more possibilities than using pvpython for integration.

Ah, sorry, I'm thinking of the situations where the client machines don't already have a working Python shell. ParaView already has a Qt+VTK+Python software stack, along with few other marvels of Python's world... drop in PyQt and DICE will fit right in an already existing ParaView installation, almost seamlessly, as if it was just another Python module .

Originally Posted by andrjas

We're always thinking about integrating such tools into DICE, but for now we have to concentrate on building the basis for the framework.

Yes! Don't worry about the limitless possibilities, all of this is only possible if the framework is fully operational!


... I'm even thinking about an embedded LaTeX/wiki editor for inline journalling/documenting and reports... there's even IPython Notebooks... oh the possibilities...

[andrjas]

@wyldckat:

• enGrid: We'd have to look how we can port the QWidgets to QML components. If the mesher is fully separated, that shouldn't be a huge problem. I hope there aren't any big dependencies. Btw, is the mesher based on NETGEN?
• parametric geometrical modelling: Actually one of the first ideas we had Shouldn't be that hard to implement, since it's "just" scripting.
• pythonFlu: Scripting a solver should already be possible, but integrating it visually into DICE, like in Blender's node editor groups, is a lot of work...

Yep, the possibilities are endless...

[fra76]

@andrjas
No, I'm afraid that the Qt/PyQt/VTK code we wrote is not going to be published.
However it is quite tailored around a specific application, no near as general as what you are writing!

Francesco

[Ros]

Hello everyone,

we finally have decided to move our current development to a public repository.

Since the last post and the feedback we got, we have rewritten the backend in python and are now using PyQt so the C++ code is mostly gone. DICE is still only a preview of the concepts we created and is not really intended to be used as a stable working environment. This alpha-release includes some simple surfaceUtilities, cfMesh and snappyHexMesh app and has also a lot of bugs .

You can download the source code or a build for Ubuntu (tested with Ubuntu 14.10) here:

http://dicehub.net/download/

The github repository is located here:

https://github.com/diceproject/dice-dev

There are a lot of things to do, especially the visualization with VTK.
Our (current) roadmap can be found here:

http://dicehub.net/roadmap/

What are your thoughts? Is it something that you think is worth further development or does it need some drastic changes?
Any feedback or contribution is welcome!


Thanks!

[chriss85]

I have tried to use the compiled version on Kubuntu 14.04, I'm getting the following error:
./DICE: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version 'CXXABI_1.3.8' not found (required by ./DICE)

I assume you're linking against some other version of libstdc++, what do I need and how to set it up? Some googling points to adding the path of the correct version to LD_LIBRARY_PATH.