[alquimista]

Originally Posted by BrendaEM

Looking at OpenFoam objectively, I assert that the decision to stop support on helper pre-processing applications for Openfoam was indeed a dubious mistake. Why should parafoam, exist for post processing, and not employ a preprocessing? I feel that it is a logic that is inconsistent.

paraFOAM is just a script to run ParaView. You can make a CFD code to have an output readable (basically mesh with variable data) wich is not similar to have an specific way to prepare the case to run.

I'm comfortable with the OpenFOAM structure and I find it easy to work it. Maybe OpenFOAM would be more useful with many GUI tools for some kind of people that likes it, but where is the efficiency there? How many advantages has pre-processing with some graphic user interface?

[dahicke]

alquimista,

To answer your question about GUIs, the advantage with a GUI is that the case can be manipulated in a CAD like manner to specify BC patches, inlet and outlet conditions, movement of objects in the simulation volume, etc. While doing this, it would provide validation of these inputs, visual indications of correctness of the simulation, provide tool tips, and application help. It is inefficient to use config files to run a simulation like this. It is the difference between using a command line interface and a 3D CAD Modeller like FreeCAD to produce a 3D CAD Model.

The advantage is that it is easier to see relations between elements of the simulation in a 3D graphic view than it is to try and correlate the numbers from several config file in your head. This makes the simulation more likely to be accurate to the what was intended by the simulation designer. By adding validation, correctness of the simulation is strengthened.

Granted this is sort of an open source project run by a company selling services.

[alberto]

I agree a GUI is helpful, especially when you have different cases to setup quickly. I see a GUI essential for pre-processing (CAD), and post-processing. However, I don't see it as an essential aspect for CFD codes (meaning the crunching number engine), and it actually often represents a limitation in terms of efficiency when you have to perform repetitive work like in parametric studies / uncertainty quantification analysis, because of the quite limited scripting capabilites. Also, specifying BC's in a GUI when you have many might not be exactly fun, while you could user either regular expressions, or script the setup once for all if you have a file-based setup.

Data validation is what I would find more useful, however this could be implemented at the level of the solver. It is partially there already for keywords, and it's not terribly hard to add it to inputs (I did this for some of my own solvers).

In short, ideally, both aspects, GUI and text-based setup, could be combined to leverage their advantages based on the specific use-case.