[nickninevah]

Hi all,

So I'm curious, are there any plans to reintroduce a preprocessor GUI in later versions of OpenFOAM?

I understand that FoamX was removed in version 1.5. And after a little cruising around the forums here, I think I'm starting to understand why. It seems that getting FoamX to work was too complicated with all the different version of Java that people had on their system. And removing FoamX also opened up several other programming options for the FOAM solvers. You can see that I am not a computer scientist or full time programmer. So I don't really have the knowledge to appreciate the trouble that was involved in keeping FoamX. But I understand that it was probably a good decision.

I am a professional CFD user though. And as such, I do understand that not having a preprocessor severly impaires the efficiency of using OpenFOAM. Many people have made the argument that the control files are very logical and easy to use. I completely agree. I also think that they are very inefficient to anyone who does not know ALL the options for each text file BY HEART. True, I can flip back and forth between the user guide and the text files to eventually work it out. But if I'm working in an industrial setting, every hour of my time is billed to a project. To maintain competitive CFD work, I need to be very efficient with my time. I can't spend the effort it takes to flip back and forth between files. (And of course the extra effort to correct typos.) Plus, as a CFD user, seeing graphical output to relate my settings to my specific model just adds a whole new level of comfort and confidence that I am specifiying the correct inputs. It gives me one less thing to worry about when I am trying to find my why model won't run.

So I understand that FoamX needed to go to allow further development of other features for OpenFOAM. Good move. But I don't think that means OpenFOAM should lose a preprocessor GUI all together. Again, I really don't understand the complexities of putting together a whole slew of programs like OpenFOAM. But could this just mean that the strategy of FoamX doesn't work and we just need to think of a new way to implement a preprocessor GUI? Would it be easier to code the GUI in C++ instead of Java and have it only run on the local machine? I know I'm completely over simplifying this. But I hope this at least helps the developers get a better user perspective.

FoamX can go. But please put in SOME preprocessor GUI.

[Ahmed]

Yes, I agree with every letter in this post
Hope the developers are reading the forum

Good Luck to all

[anon_c]

you really right i am new in openfoam and even in CFD but it is much easyer to use fluent

we need that

[olesen]

Originally Posted by nickninevah

...
Would it be easier to code the GUI in C++ instead of Java and have it only run on the local machine? I know I'm completely over simplifying this. But I hope this at least helps the developers get a better user perspective.

You aren't actually oversimplifying that much. A C++ gui would be much less work than java, and would be able to reuse many bits of the existing library. I suspect the only major problem is that someone has to write it, or pay someone to write it.

[braennstroem]

Hi all,

if one really needs a gui, then a good base could be mayavi2 in combination with pyFoam... though it's python, but mayavi2 is quite simple to extend :-)

Regards!
Fabian

[evrikon]

Hi Fabian,

can you please give a link to mayavi2? I would like to make a first impression.

Yes, we need a GUI. I describe my own impressions from daily work with OF. Of course I can work with a text editor but if I need to make some specific operations (e.g., mesh manipulations) first I need to look into old cases and consult myself how I did it in the past (or ask experts in the forum). In an commercial solver you can simply go through the process flow by clicking on buttons.

On this place I should say that the GUI is only a method to save time. It is clear that not all the solver options can be covered by GUI. The same situation is in Fluent: you can always run a command from text user interface but not all of them are implemented in a Fluent GUI.

Who is willing to write a GUI for OF?
If we would have lets say 3 developers who can really do that we can start an open source project. Alternatively one can reactivate XFoam.

[l_r_mcglashan]

Would Qt not be a good thing to use? Portable and easy to design GUIs, plus it's in C++. Seems very easy to use from what I've seen of it.
As said before, there are some commercial GUIs:

http://www.cfd-online.com/Forums/ope...pointment.html

[Ahmed]

I was browsing the featflow web portal, they have a nice preprocessor, DeViSoR.Grid 3D
http://www.featflow.de/
May be, and this is just a thought, the readers of this forum and true users of OpenFOAM could join forces and modify this free and Open Source programme to write the output in the OpenFOAM format.

[Ahmed]

Originally Posted by evrikon

Hi Fabian,

can you please give a link to mayavi2? I would like to make a first impression.

Yes, we need a GUI. I describe my own impressions from daily work with OF. Of course I can work with a text editor but if I need to make some specific operations (e.g., mesh manipulations) first I need to look into old cases and consult myself how I did it in the past (or ask experts in the forum). In an commercial solver you can simply go through the process flow by clicking on buttons.

On this place I should say that the GUI is only a method to save time. It is clear that not all the solver options can be covered by GUI. The same situation is in Fluent: you can always run a command from text user interface but not all of them are implemented in a Fluent GUI.

Who is willing to write a GUI for OF?
If we would have lets say 3 developers who can really do that we can start an open source project. Alternatively one can reactivate XFoam.

mayavi2 is available on the debian repository

[madad2005]

I've actually been working on a GUI interface for OpenFOAM using PyQt4 in my spare time. It will only suffice for my own purposes for the moment, which is using the few variations of the simpleFoam solvers. However, I do plan to post it somewhere so anyone can use it and extend it for whatever they want. So far, it can read in the boundary file and you can set solvers and boundary conditions as required. I plan to have it write out all the files you require to run the solver, and include an interactive run-time option so you can watch the convergence of residuals and loads as it runs. I haven't had much time to spend on it, but I'm hoping in a couple of weeks to have a basic interface ready for initial testing and feedback on the layout of the windows.

It is my first attempt at writing a proper GUI and the code is very patchy, but so far it works. It will most likely require a proper re-write at some point. It would be nice to have it interact with PyFoam at some point too, but that is well into the future!

[braennstroem]

Hi,

I attached a really simple stupid test using pyFoam inside of mayavi2 with a plugin... basically mayavi2/traits-ui provides the gui and pyFoam does the work.

I actually prefer to combine pyFoam with urwid and emacs. It provides a fast access to the cases... you have a quick overview, can run on 'any' cluster, is flexible, can be combined with some vtk stuff, could integrate a python shell ... and is not ready ;-)

Fabian

[af631717]

Cast Net is a grid generator and also a GUI for many OF Solvers. You can handle all settings there e.g. turbulence settings etc.

It is cheap but not for free - but wonderful!

http://www.dhcae-tools.com/CastNet.htm

http://www.dhcae-tools.de/OpenFOAM.htm

Regards
Achim

[ggruber]

I agree with the thread starter.

A free and easy PreProcessor for OpenFOAM (on an early state of development) is www.discretizer.org

[titio]

Agree with the thread starter. It is needed a GUI pre-processor to improve the usability of OpenFoam, in order to reach more people.

[henrik]

Dear All,

I don't think there is a simple answer here. People will use a preprocessor in different ways and for different problems - Apart from coming from different backgrounds and having different tastes.

FoamX was never really "graphically" and to replace FoamX's functionality, I think, a TUI solution will offer a lot of potential and portability and with the right design the eye-candy could be optional.

This approach will not suffice when you want to pick patches on the screen in order to modify the boundary conditions. There are many candidates to do something along those lines - both closed and open source.

Finally, there is the issue of meshing - and we all know that there is not one solution that fits all needs. Again many products & tastes.

This is all pre-processing and wonder how much do these systems have to be integrated for me. Maybe I would rather have them seperately? Maybe they could plug into each other as well as running stand-alone.

For the moment, I would like to see a list on the Wiki which lists all the systems with an array of ticks which tells me what they are good for.

Henrik

[BrendaEM]

I also agree with the original poster, and I will add that even a GUI for pre-processing would help. There is an example of one done for CAELinux here:
http://www.youtube.com/watch?v=ElOt9qzXQ7k

Saddly, I have found CAELinux restrictive, and it's unclear if CAELinux can even be installed anymore.

It would seem logical to create a GUI front end, at least for pre-prossessing and file/folder setup.

Perhaps there could be a OpenFoam plugin system for Salome or even FreeCAD, as there is one for Code Saturne.