Openfoam Case Manager / Laucher GUI?
 

Hi,

Having worked with Code_Saturne, I am trying to get starting with Openfoam. I was wondering if there was a case manager GUI such as the Simplefoam one that ships with CAELInux, or the now defunct FoamX?

I have a cube in a box model prepared in Salome, meshed it in tetahedrons, named my inlet, outlet, and wall faces, and exported to UNV, but now there are a mariad of folders and files that have to be in place before I even run ideasUnvToFoam or even check the mesh.

It looks like OpenFoam can solve a lot of different types of cases, but I don't see a lot of documentation on how to prepare simple scripts, nor do I see firm information on which files must be in place. Some documentation does not even state that certain folders have to be in place at all.

I cannot help but think that there must be a easier way to do a simple test, even if it means that a have a .zip/tar/7z of dummy folders and a sample script to edit. It is one thing to give a rundown of all of a program's commands; it is another to give contextual information and some real world examples.

I don't know whose idea it was to remove FoamX, but it's a boom for commercial solvers.

Any help would be appreciated.

The short answer is that there is no open-source GUI.

It is not so complicated. Look for a tutorial of the solver you want, copy your UNV file into it, and run the mesh converter. You do not have to set-up a case or a file to import a mesh.
After this, open /constant/polyMesh/boundary and use the names listed there to define the boundary conditions in the 0 folder.
In the constant folder you set physical properties and in system the numerical and solution settings.

There are training courses to learn how to use OpenFOAM, if you do not have time to dig into the code (http://www.openfoam.com/training/ ).

You can use pyFoam to automate many operations. You can download it from the wiki.

Best,

I am sorry, but what you stated was not consistent with what ideasUnvToFoam does. As stated elsewhere in multiple threads, as well as my experience, without certain folders in place, ideasUnvToFoam will error out on exit, and not proceed. That's one of the things I have problems with.

Whether or not the process is complicated or not, it is cryptic. What was the "0" folder/directory name was supposed to represent is not clear to me.

I do not have money to spend of seminars. I would have hoped that there would be enough documentation available to make the program accessible to all.

I have seen amazing results with OpenFoam, but I am still struggling with my first cube-in-a-box test case.

I implore OpenFoam to bring back a helper application, such as FoamX or CAE's SimpleFoam unless pre and post processing can be...streamlined : )

Hi!
At first you have to be able to run/ compile the cavity tutorial.

Understand the structure of a openfoam case folder.

Try to re-run the icoFoam/cavity using the official tutorial and take a look of this other tutorial

http://web.student.chalmers.se/group...alkThrough.pdf

saludos!

As I wrote, you simply need to clone a case (with this I mean, copy one of the tutorials, for example) to be able to import a mesh. The general idea of how mesh conversion works, with specific examples is clarified in section 5.5 of the user's guide.

The structure of a case is explained in detail in Chapter 4 of the User's guide, which you can find in ~/OpenFOAM/OpenFOAM-2.1.x/doc/Guides-a4/

I agree documentation could be better. However, if you have some time to spend learning OpenFOAM, and you ask questions on the forum, you can learn what you need too (I have never had formal OF training, for example).

I would suggest you go through the tutorials in the User's guide and the programmer's guide to familiarize with the basic concepts of OpenFOAM. After that, you will have to start working on a simple case you are familiar with, so that you can check if you can reproduce the results you expect correctly.

I am not sure if this is going to happen. I agree however it would make OF a bit more accessible to new users.

Best,

Penn State Tutorial Walkthrough Notes:

The OpenFoam tutorials must be copied over for the tutorial instructions to work as shown in "Getting Started" on www.openfoam.org/download/git.php

On page 4, the tutorial paths have changed adding "/incompressible" as in $FOAM_RUN/tutorials/incompressible/icoFOAM/cavity

3.) Apparently, the sourced environment variable $FOAM_RUN will point to ~/OpenFoam/username-2.0.1/run whereas username will be your username and 2.0.1 will be the version of OpenFOAM you are using.

On page 6, in paraview/parafoam "accept" has been changed to "Apply"

On page 6, I believe to view the same results, the user might click on the Object inspector "Display" tab, and in the "Color" section choose "p" . To turn on the scale click on "Edit Color Map" and then "Color Legend" and then choose "Show Color Legend". To make the base color green as in the tutorial, select "Choose Preset" and then "Blue to Red" HSV and then okay it.

[At this point the user might wonder why a high-school drop-out, armed only with a GED, physics lecture videos from MIT and hearsay CFD knowledge from a Ames Research Center retiree, and who struggling to live while in poverty, in the heart of Silicon Valley, is updating class notes for Penn State University professor. Okay, we forge onward....]

On page 9, it might be worth suggesting that the student type "ls" to show the directory contents. In that way they will see the directories that are being discussed, or "ls -l" to see if these things are files or directories/folders.

On Page 11, it might be worth mentioning who aren't familiar with linux/unix that blockMeshDict is a text file that can be read with more, or gedit if using on Gnome. This also might a good place to mention that OpenFoam deals with SI units, such as Meters, which is why the convertToMeters command is invoked.

On page 17, it might also be worth mentioning that controlDict is a text file and not a directory which also can be read, as above.

On page 30, Looking for "PBiCG"? I suspect that we are using a different solver now.

On page 35, we need to add "incompressible" in the path for copying. For those who don't know, to launch Allrun , we ./Allrun from the command prompt.

Sorry but I dont understand your problem!
I think that the first instruction is only a "precaution" to keep the clean tutorials files.
You can copy this file wherever you want and then run it just typing the correct solver name

Saludos

Apparently, the pathlist has changed since the tutorial/lecture notes were prepared.

If anyone could post some practical tutorials on using Openfoam for CFD, that would be appreciated.

For real-world use, after preparing meshes, the pre-processing and directory structure preparation seems formidable without helper utilities. I saw one webpage that dealt with which directories need to be in place to convert invoke proper mesh conversion, but the documentation seems incomplete.

What seems missing how to prepare original data for solving. Yes, we have test cases and their invocation, and we also have a library reference, but the stuff information between, such as workflow from .unv-to-solve information seem sparse.

OpenFoam is power software, deserving excellent documentation.

Actually no. OpenFOAM does not require cases to be in a specific path at all. The only requirement is the directory structure of the case, which is standard

0/
constant/
>>polyMesh/
system/

On a side note, I can't stress more how easier it would be if users read the User's guide carefully from the beginning to the end, while trying to put it in practice. I know it is not complete, but it surely contains all users need to know to avoid these mistakes.

Best,

Maybe you should describe the problem you are trying to solve, so we can give you specific suggestions.

I would like to see it too, because the procedure for mesh conversion is very standard, and does not require complex setup, as I tried to explain to you more than once ;-)

This has many reasons. One is that the business model also relies on providing training, which is in a clear conflict with providing free documentation. However, if you understand what you are solving for, and you have enough time to spend on understanding how OpenFOAM works, you can also proceed by yourself, with the help of the community.

Best,

As I stated before, the path issue is that the paths where the OpenFoam stores its tutorials data have changed since the tutorial have been written, and that will needlessly frustrate users. The tutorial needs to be updated.

As I have also stated before, if OpenFoam does not have certain folders in place, it will exit out with an error, just as MIT has mentioned in here and someone has mentioned here.

Also, as I stated, information on workflow is sparse, and between what you stated and the other two links, you will find dependencies as which files and directories need to be in place, and when.

Am I to assume that no less than 11 files and folders need to be in place to run the test?

As for a specific problem, I want to make a fresh study of cube in a box. I have a unv. file already exported with the (inner) cubewalls, inlet, outlet, and for the sake brevity we can call the rest of the faces testsection.

1.) Which files and folders must I create before invoking ideasUnvToFoam ?
2.) What else needs to be done before I invoke the solver?
3.) If I want compressible, as in air, does the process change?

If OpenFoam is to be useful for academic purposes, should it not have good documentation? If there is a conflict of interest, should that not be resolved?

Just put your unv mesh file in the same main directory of your case. For example if your are working with simpleFoam solver..

Case name = backstep

Create a folder named backstep, It can be located anywhere you want, but for convenience put it in tutorials/incompressible/simpleFoam
This new "backstep" folder should contain this folders:
0/
constant/
system/
and the file
name.unv

The you have to open a new Terminal and go to this folder, then write ideasUnvToFoam name.unv ( where name is the name of your unv mesh file :eek:)
After this process you have to check the "boundary" file inside constant/polymesh and see if the patch name/type are correct.
Same for 0/ folder check the BC ( try to work with laminar case first aboiding turbulence bc)
If anything is correct just type simpleFoam on the terminal..

check names/bc/properties.. etc
but all the tutorial files are ready to run. Try to keep it simple, icoFoam/simpleFoam are great to learn how. Try to modify the cavity tutorial blockMesh and put some inlet/outlet and run it like a laminar flow between parallel plates..
It is really similar once you have learn how to configure and run cases, but try with the easiest ones first

Sorry about my English I´m doing my best =P
Saludos!

First of all, these tutorials are not official, but provided by users like you. As a consequence, it is responsibility of these users to keep them up to date, which, unfortunately, happens rarely, because it is a very time-consuming activity.

The tutorial on the MIT website is correct in explaining the details of mesh conversion. What I am trying to tell you is that you do NOT need to write those configuration files every time you need to set-up a case.

The typical procedure to set a case up is the following:

1. Decide what type of simulation you need to perform, in order to pick the correct solver you need:
   • steady/unsteady?
   • single phase / multiphase?
   • laminar/turbulent?
   • if turbulent, RANS/LES?
2. Find the tutorial for that solver that resembles your case more closely, and copy it in your work area.
3. Copy the file containing your mesh into the main directory of the case (the one containing 0, constant and system directories).
4. Run the mesh converter.
5. Open the file constant/polyMesh/boundary and read the names of the boundary conditions (they will be the same you used in the mesh generation tool, usually)
6. Set the boundary and initial conditions in the directory 0 by editing the relevant files
7. Set the models modifying the files in the constant directory (they are solver-specific)
8. Set the numerics in fvSchemes and fvSolution. Configure time-step, simulation time, ... in controlDict.

This approach saves you a lot of time. If you often use the same setup, you can clone your case by simply copying it again. pyFoam helps in managing these situations.



I think it is much simpler to base the simulation setup on a pre-existing case, which is often possible given the high number of tutorials.

For what concerns the sparsity of the information, I agree. However OpenFOAM is open source, and the wiki is always waiting for contributions ;-)

I think what I said above answers this question too.

I will try to explain. I do not know what solver you need, so I assume you want to use an unsteady single-phase solver, with a laminar flow. In such a case you would use pisoFoam (or, eventually, pimpleFoam).
So, you would go to ~/OpenFOAM/OpenFOAM-2.1.x/tutorials/incompressible/pisoFoam/ras/ and copy the cavity test case.
Then you rename it to something you like, and the copy your UNV file into the directory. At this point you can run the mesh converter.

Open the constant/polyMesh/boundary file to check the names of your boundaries are preserved.
Open finally the files U, p, k, epsilon, and set the boundary conditions, using their name to identify them (see how it is done in the cavity tutorial).
You'll have to set the numerics in fvSchemes and fvSolution, and the time stepping / saving information into controlDict.

The process does not change. The solver changes (you would need, for example rhoPisoFoam (you find the list of solvers in the User's guide!). Clearly, each solver requires different settings, but you can refer to the corresponding tutorial.

You are welcome to propose a working solution that leads to better documentation.

Best,

Thank You, I really think that you both are trying to help me.

I just got home late. I will look at it in the morning. Apparently, the controlDict needed to be written before the IdeasToFoam conversion process is done?

Send me your email direction by pm

I will send you a really simple case: flow between parallel plates running on laminar simpleFoam under blockMeshdict then modify it and try to import one unv mesh file.


Saludos

Yes, you need to have the controlDict file in the system directory in place. As said, just copy a tutorial for the solver you plan to use (for example pisoFoam), and follow the steps we explained above.

Best,

Greetings to all,

Although I'm coming in rather late to this thread, and since this hasn't been mentioned before on this thread, here's a good link about GUI's for OpenFOAM for future reference: http://openfoamwiki.net/index.php/GUI

Best regards,
Bruno

As a new user, I still find OpenFoam's file structure and pre-processing dependencies needlessly confusing and poorly documented.

The tutorials I have found tell you what to do, but do not give me a good sense of what I am doing, so the jump between following the tutorial and creating a new case from scratch is dreadful.

Packaging test cases with OpenFoam does not equal documentation. I wish there was enough documentation to re-create the test cases. Even if I am successful, it is laborious to learn something from taking it apart and examining it, rather than having information on why things are they way they are. For instance, if the 0 folder had been named initial or initial_condition or something such as that, I would have known what it was. Or, if the 0 folder was in another folder named "timestep" or "time" it would have meant something to me.

[I have been working with computers since 1984, and I have found benefit of having meaningful file and folder names.]

Even the gracious people who have helped me in this thread have omitted important steps.

The commercial products which employ openfoam are out to the question for students, which leaves 2 open source packages, which mesh and they are interesting, but young.

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.

[Sorry, I have been sick for the last few weeks.]

Ask questions, and don't worry to ask something trivial. Use the search function to see if there is an answer already, and if you do not find anything with reasonable effort, open a new thread and ask.

I agree with the fact that having the theory documented would be useful, however, nobody stops you from contributing to the wiki and write down what you learn while you learn it, if you have the time. It is how open-source projects work.

That's a conventional decision. If you spend 10 minutes reading the structure of the case, which is unchanged in every example, and, as we told you, it is explained in the user's guide very clearly, it does not take a lot of effort to associate the 0 directory to the initial condition.

I could object to your suggestion of putting time-steps in a subfolder because it would add complexity to the structure of the case :D


That's because you did not ask any specific question. Instead you made a long list of opinions about how OpenFOAM should have been implemented. Like it or not, OpenFOAM won't adapt in a day to your needs, you have to spend some time learning its logic, as with any other tool.

If you study, and have an email address from an academic institution, there is at least one mesher you can download (GridPro, use google to find it), and you can use Salome. This can simplify the generation of the mesh of a great deal, in case of complex geometries.

Because, unfortunately, there is no good pre-processing open-source tool, also because meshing technology is more complicated than post-processing.

Best,

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?

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.

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.