CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > Software User Forums > OpenFOAM

DICE - OpenFOAM GUI project

Register Blogs Members List Search Today's Posts Mark Forums Read

Like Tree35Likes

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
Old   January 7, 2015, 07:38
Default DICE - OpenFOAM GUI project
  #1
Ros
New Member
 
Rostyslav Lyulinetskyy
Join Date: Jul 2011
Location: Stuttgart
Posts: 14
Rep Power: 14
Ros is on a distinguished road
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
Ros is offline   Reply With Quote

Old   January 7, 2015, 15:10
Default
  #2
Senior Member
 
Philippose Rajan
Join Date: Mar 2009
Location: Germany
Posts: 552
Rep Power: 25
philippose will become famous soon enough
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
philippose is offline   Reply With Quote

Old   January 7, 2015, 16:45
Default
  #3
New Member
 
Andreas Rjasanow
Join Date: Jan 2015
Posts: 4
Rep Power: 11
andrjas is on a distinguished road
Quote:
Originally Posted by philippose View Post
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.

Quote:
Originally Posted by philippose View Post
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.

Quote:
Originally Posted by philippose View Post
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 ;-)

Quote:
Originally Posted by philippose View Post
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.

Quote:
Originally Posted by philippose View Post
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.
andrjas is offline   Reply With Quote

Old   January 7, 2015, 17:25
Default
  #4
Senior Member
 
Philippose Rajan
Join Date: Mar 2009
Location: Germany
Posts: 552
Rep Power: 25
philippose will become famous soon enough
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
philippose is offline   Reply With Quote

Old   January 8, 2015, 05:18
Default
  #5
Senior Member
 
Hannes Kröger
Join Date: Mar 2009
Location: Rostock, Germany
Posts: 123
Rep Power: 18
hannes is on a distinguished road
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
hannes is offline   Reply With Quote

Old   January 8, 2015, 07:36
Default
  #6
Ros
New Member
 
Rostyslav Lyulinetskyy
Join Date: Jul 2011
Location: Stuttgart
Posts: 14
Rep Power: 14
Ros is on a distinguished road
Quote:
Originally Posted by philippose View Post
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.

Quote:
Originally Posted by philippose View Post
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.

Quote:
Originally Posted by philippose View Post
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.
Ros is offline   Reply With Quote

Old   January 8, 2015, 08:24
Default
  #7
New Member
 
Andreas Rjasanow
Join Date: Jan 2015
Posts: 4
Rep Power: 11
andrjas is on a distinguished road
Quote:
Originally Posted by hannes View Post
this looks like a very interesting project.
Thanks. Glad you're interested.

Quote:
Originally Posted by hannes View Post
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 ;-)

Quote:
Originally Posted by hannes View Post
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...

Quote:
Originally Posted by hannes View Post
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.

Quote:
Originally Posted by hannes View Post
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
andrjas is offline   Reply With Quote

Old   January 9, 2015, 05:40
Default
  #8
Senior Member
 
Join Date: Oct 2013
Posts: 397
Rep Power: 18
chriss85 will become famous soon enough
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
chriss85 is offline   Reply With Quote

Old   January 9, 2015, 16:29
Default
  #9
Senior Member
 
Francois Beaubert
Join Date: Mar 2009
Location: Lille, France
Posts: 147
Rep Power: 17
francois is on a distinguished road
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
francois is offline   Reply With Quote

Old   January 10, 2015, 17:46
Default
  #10
Retired Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,974
Blog Entries: 45
Rep Power: 128
wyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to all
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
wyldckat is offline   Reply With Quote

Old   January 11, 2015, 06:36
Thumbs up Nice tool!
  #11
Senior Member
 
Francesco Del Citto
Join Date: Mar 2009
Location: Zürich Area, Switzerland
Posts: 237
Rep Power: 18
fra76 is on a distinguished road
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
fra76 is offline   Reply With Quote

Old   January 12, 2015, 08:21
Default
  #12
New Member
 
Andreas Rjasanow
Join Date: Jan 2015
Posts: 4
Rep Power: 11
andrjas is on a distinguished road
Quote:
Originally Posted by chriss85 View Post
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 ;-)

Quote:
Originally Posted by francois View Post
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.
andrjas is offline   Reply With Quote

Old   January 12, 2015, 10:00
Default
  #13
Senior Member
 
Join Date: Oct 2013
Posts: 397
Rep Power: 18
chriss85 will become famous soon enough
Quote:
Originally Posted by andrjas View Post
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?
chriss85 is offline   Reply With Quote

Old   January 12, 2015, 11:32
Default
  #14
Senior Member
 
Join Date: Mar 2010
Location: Germany
Posts: 154
Rep Power: 16
cutter is on a distinguished road
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
cutter is offline   Reply With Quote

Old   January 13, 2015, 10:28
Default
  #15
Ros
New Member
 
Rostyslav Lyulinetskyy
Join Date: Jul 2011
Location: Stuttgart
Posts: 14
Rep Power: 14
Ros is on a distinguished road
Quote:
Originally Posted by chriss85 View Post
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.


Quote:
Originally Posted by cutter View Post
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.

Quote:
Originally Posted by cutter View Post
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.

Quote:
Originally Posted by cutter View Post
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 likes this.
Ros is offline   Reply With Quote

Old   January 13, 2015, 19:14
Default
  #16
Retired Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,974
Blog Entries: 45
Rep Power: 128
wyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to all
Quote:
Originally Posted by andrjas View Post
@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

Quote:
Originally Posted by andrjas View Post
  • 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

Quote:
Originally Posted by andrjas View Post
  • 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.

Quote:
Originally Posted by andrjas View Post
  • 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...

Quote:
Originally Posted by andrjas View Post
  • 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 .


Quote:
Originally Posted by andrjas View Post
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...
wyldckat is offline   Reply With Quote

Old   January 17, 2015, 05:43
Default
  #17
New Member
 
Andreas Rjasanow
Join Date: Jan 2015
Posts: 4
Rep Power: 11
andrjas is on a distinguished road
@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...
andrjas is offline   Reply With Quote

Old   January 25, 2015, 03:32
Default
  #18
Senior Member
 
Francesco Del Citto
Join Date: Mar 2009
Location: Zürich Area, Switzerland
Posts: 237
Rep Power: 18
fra76 is on a distinguished road
@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
fra76 is offline   Reply With Quote

Old   April 21, 2015, 19:03
Default
  #19
Ros
New Member
 
Rostyslav Lyulinetskyy
Join Date: Jul 2011
Location: Stuttgart
Posts: 14
Rep Power: 14
Ros is on a distinguished road
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!
francois, elvis, bigphil and 7 others like this.
Ros is offline   Reply With Quote

Old   April 24, 2015, 04:50
Default
  #20
Senior Member
 
Join Date: Oct 2013
Posts: 397
Rep Power: 18
chriss85 will become famous soon enough
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.
chriss85 is offline   Reply With Quote

Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
Best GUI for OpenFOAM: Helyx OS or Salome? BhaluBear OpenFOAM 60 March 11, 2024 10:23
TreeFoam: New GUI for OpenFOAM? JR22 OpenFOAM 4 September 11, 2023 14:40
Run OpenFOAM GUI Caluca OpenFOAM Installation 7 September 11, 2023 14:26
ANSYS Workbench on "Uncertified" Linux Distros hsr CFX 289 April 20, 2023 10:23
My first OpenFOAM Project m.nichols19 OpenFOAM 1 June 4, 2010 14:46


All times are GMT -4. The time now is 17:06.