CFD Online Discussion Forums

CFD Online Discussion Forums (
-   enGrid (
-   -   Opensource mesh generator (

ogloth July 23, 2008 06:46

Opensource mesh generator

We have developed an open-source mesh generation program named ENGRID; it is licensed under the GPL. The current version (0.9) is in a beta state and we would be happy if people download and try it. It creates unstructured grids with prismatic boundary layers. The prismatic layer generation is a new development, done in-house by enGits, and the tetrahedral part is being created by the NETGEN library (

Currently the tool cannot create surface meshes, but it can import surface meshes that have, for example, been created by Gmsh ( or NETGEN.

The ENGRID homepage can be found here:

A very rudimentary documentation is also available.

Currently export to OpenFOAM is done via the Gmsh format (v1.0), but is is planned to provide native OpenFOAM support in the 1.0 release (before the end of 2008)

Any feedback is most welcome!!


girogirozakk November 25, 2008 20:12

Hello, Oliver. enGrid is so n
Hello, Oliver.
enGrid is so nice for me,very thanks.
Now I try to make a few sample-mesh on enGrid.

so,I want to know, polyhedral mesh can use in the future of enGrid?


ogloth November 26, 2008 05:24

Hi Giro, I had a look at yo
Hi Giro,

I had a look at your manifold example; it looks nice -- thanks for making that available.

As you probably noticed we put enGrid on SourceForge and there is a mailing-list and anonymous CVS available. Now we also have a URL that shouldn't change anymore and is somehat nicer than the dynamic php URL we had before:

You can (try to) use polyhedral grids already. If you use the latest snapshot there should be an "OpenFOAM" option in the "Export" menu. This exports a partially dualised mesh. You need to select the OpenFOAM case directory and enGrid will export the mesh directly to the OpenFOAM format. The OpenFOAM case needs to exist already, because at the moment enGrid doesn't create the necessary directory structure itself. The prismatic boundary layers are kept as they are and the tetrahedral part of the mesh is dualised. Be warned, however, that the current implementation is incredibly slow and memory hungry. It will be re-written soon. For now, just try it and see if it works. The launch vehicle example from the enGrid website had around 1 million cells (before dualisation).

'just had a look at your grid and I suspect that you will get problems running that. As a general rule prismatic layers can only "end" on a domain border, not inside the domain, which is what seems to happen in your case (see image below).
To change this I have introduced another boundary code (8) for the little face on your step in order to "wrap" the boundary layer grid around the step (see image below). You can still apply an in or out-flow boundary condition on this step if you want to. If you contact me by email (or via the mailing list) I can send the modified grid to you.

I checked the polyhedral export and discovered a bug. If you check out the latest CVS, or download the latest windows binary, you should get a working version for your case (see image below).

If you subscribe to the mailing list we'll keep you updated on the status of polyhedral grids and direct OpenFOAM support.

Thanks for your interest in enGrid,

girogirozakk November 26, 2008 06:50

Hi Oliver. Thanks for your
Hi Oliver.

Thanks for your kindness.
I was very helpful your sentence and images.

Now , I was registered to mailing list.
Please send me the modified grid(vtu and step-file).


vinz November 26, 2008 07:00

Dear Oliver, I would also
Dear Oliver,

I would also like to try your software. Maybe first on a very simple model, like a wheel with cylinder shape or a spoiler.
In your first post, you say it is not possible to import an stl and directly work on it.
Is it something that changed in the last releases or still on the to-do list?
Is there a way to specify the boundaries of my domain directly inside your software or should I import them in the same way I import my stl?
Would it be possible to have a brief overview of the steps needed to go from my stl file to a mesh usable inside OpenFOAM?

Thanks in advance.


ogloth November 26, 2008 07:22

You still need a decent surfac
You still need a decent surface mesh to get started. If your STL file has a decent surface mesh then you can import it and start from there. Otherwise you could try NETGEN to get a surface mesh. If you want, you can send your example to me and I'll have a look.

Reading STL files and creating surface grids from there is number one on the priority list of developments, but I don't think that there will be anything reliable before beginning of 2009.

braennstroem March 19, 2009 14:49

Hi Oliver,

nice tool, I just started to test it (there are some precompiled packages on ).
Do you plan to integrate some other pre-processing functions except setting the boundary conditions?

Ahmed March 19, 2009 19:57

Are you sure you wrote your post today this year of 2009, during the past 4 month I have tried several times to log on their web portal, but it was always down, I thought they have ended the development of the project.

temporary outage is the usual message firefox displays when trying to log on their web portal

braennstroem March 20, 2009 09:48

not today, but yesterday ;-)
This works for me:

ogloth March 27, 2009 06:28


The website had very little downtimes in the last couple of months, but I must admit that the URL might be a bit confusing at times. We are in the process of moving everything to our in-house server which then will have the URL For now there should be a re-direction in place that brings you to our website. So the following URLs should work and will keep working in the future (please drop me note at ogloth [at] if you have problems).

The ENGITS website:

The ENGRID website:

We also have our own little forum for discussions related to ENGRID. This forum can be reached via:

To answer the question about other pre-processing options: We are currently working on our own surface-meshing implementation. It should be available at some point this summer (maybe July). You will still need an existing triangulation as input, but this could be a really bad triangulation (for example something like the STL output from a CAD package). STEP and IGES import might be the next step, but this will depend on funding and user request.

Thanks for your interest in our software,

Ahmed March 28, 2009 23:23

what version of Qt is recommended

ogloth March 30, 2009 11:54

Qt version 4.5.0 works well, but earlier 4.x releases will probably be fine too.

mahaputra May 4, 2009 03:29


Originally Posted by ogloth (Post 211298)
Qt version 4.5.0 works well, but earlier 4.x releases will probably be fine too.

Dear Oliver Gloth and all of EnGrid Developers

really thanks forENGRID. this software is really fantastic.

i had installed its windows version on my vista. and already converted several *.stl files of mine.


i found too difficult to install this software on my Ubuntu 8.10

i follow the instruction on

tested to download and install on ---- > user@user-desktop:~/engrid_src$

but when i type ./engrid , it informed that :

bash: ./engrid: No such file or directory

should i move all of the files on the /engrid_src to /usr/local/bin ???

please give me the guideline , step by step . since im not really good in the linux :(

my qt version is Using Qt version 4.3.5 in /usr/local/Trolltech/Qt-4.3.5/lib

im really need your help. thanks

NB : why there is no activity in the mailing list ?

ogloth May 4, 2009 04:06


If you have a look at our forum ( you will find some more detailed information on compiling ENGRID. There might also be a binary package available for your LINUX installation. Should you still be stuck, please re-post your question to the ENGRID forum and we'll help you.

To answer your question about the mailing-list: We started the forum, because it seems easier to use compared with the mailing-list. Also, ENGRID is still quite new and so far it has a failrly small user community.


Stephan.Lange October 6, 2010 11:01

Hey Guys,

I'm using enGrid my first time and I want to start with the two tutorials. I follow your description in the enGrid manual but when I will create the grid with Mesh >> create prismatic boundary layer and selecting boundary conditions 1 and 2 the program shows me, after selecting the "OK"-button, the following error:

Boundary code 1 is not part of the volume".
file: guicreateboundarylayer.cpp
line: 90

Can someone help me, please?

Kind regards

philippose January 24, 2011 02:39

Hello and a Good Day to everyone :-)!

I have a couple of questions regarding the Engrid meshing tool:

1. Is this project still in active development? The last submission to the Git repository was in November of last year.

2. Has anyone tried to compile the last stable version Engrid-1.2.0 which is available as a tar file from the Sourceforge project page? Either in Linux or Windows... And most importantly... succeeded?

3. Has anyone tried to compile the latest Git version of the tool after pulling it from the repository and made it through to the end successfully?

The reason why I am asking is because it seems like there are some fundamental issues in the source code such as:

1. Trying to use dynamic allocation for arrays
2. Possibly incorrect use of C++ template variables
3. Use of the keyword "or" instead of the C++ "||" operator in a couple of places

And so on.....

Have a nice day ahead!


ogloth January 24, 2011 07:04


let me try to reply politely to this rather rude post.

1. Is this project still in active development? The last submission to the Git repository was in November of last year.

The last submission is three days old and yes the project is very much alive. A key point to keep in mind, however, is that we are a tiny company which has to fund all developments via commercial income; we do not have the luxury of a university paying our salaries.

2. Has anyone tried to compile the last stable version Engrid-1.2.0 which is available as a tar file from the Sourceforge project page? Either in Linux or Windows... And most importantly... succeeded?

Yes many people have -- instead of ranting on this forum you could ask specific questions and, most importantly, give information about the kind of compiler error you get.

3. Has anyone tried to compile the latest Git version of the tool after pulling it from the repository and made it through to the end successfully?

Currently the version in the GIT repository is organised slightly differently from version 1.2; the key difference being that most functionality has been put into a library which is then linked to the program. The reason for this is to enable the use of plugins.

The reason why I am asking is because it seems like there are some fundamental issues in the source code such as:
1. Trying to use dynamic allocation for arrays

What is wrong with dynamic allocation? I thought the times of static FORTRAN arrays were over...

2. Possibly incorrect use of C++ template variables

Possibly correct use of C++ parametrised types. Where do you find incorrect use of templates?

3. Use of the keyword "or" instead of the C++ "||" operator in a couple of places

Where? Please give a file and a line number!

If you are seriously interested in using the software, I will be happy to help you get it up and running. Please keep in mind, however, that we are a tiny company and that answers are not always provided on the spot. Sometimes, it even gets forgotten, but feel free to nag if we don't come back to your problem within a couple of days.

-- Oliver

philippose January 24, 2011 09:28

Hello again,

Oh ohhh... looks like I did not project myself in the right manner, and I truly apologise if the post came off as being a rude one.... It was definitely not intended to be that way.

It was purely an exploratory mail because I had scoured through the Engrid forum, and since the forum requires registration before posting, I thought I would post here first since a lot of OpenFOAM users are aware of or use Engrid.

I shall go through the points again in a bulleted form....

1. Initially (about a week ago) I had tried to compile the Git version of Engrid, and had visited and downloaded a snapshot of the repository. At that time, the last commit was on 23.11.2010.

2. At that time when I tried to compile the Git version on windows (using qmake + Visual C++ Express..... I know you do not support this combination directly, but I am not new to this kind of stuff... so I did everything needed to get it to compile on MSVC++ Express) it did not work, and on looking deeper into the code, I started finding a lot of those issues I mentioned in the post.

3. It was a combination of the fact that the last post was on 23.11.2010 and the fact that the code seemed to be in a state of extreme flux which prompted me to ask whether the code was still in active development [Question (1) in the post].

4. Since it was the Git version, I thought I may have taken a snap-shot of a source tree which was in the middle of a heavy phase of modification (since you were shifting from a hard-coded version to a plug-in type of approach, etc...etc...)..... Hence, I decided to fall back to the last stable released version: Engrid-1.2.0 which is available as a "tar" archive on the Sourceforge downloads website.

5. After downloading engrid-1.2.0.tar, I tried the same thing again.... and was surprised to find similar errors again, but not as many as in the Git version. However, as far as I know, I don't think any compiler would have compiled the sources of engrid-1.2.0.tar without throwing up errors.... This is what prompted me to ask the questions (2) and (3) in my post.

Now to the actual issues themselves:

1. By dynamic allocation of arrays, I mean... something of this form:


  vtkIdType N_pts, *pts;
  grid->GetCellPoints(id_face, N_pts, pts);
  vtkIdType new_pts[N_pts];

Here.... vtkIdType is a normal "int" type.... which implies that the line in red is trying to directly allocate an array in run-time without using the "new" keyword or any other form of dynamic allocation allowed in C++

In engrid-1.2.0.tar you can find this in the following locations:
* surfaceprojection.h : 174
* meshpartition.cpp : 142
* guimirrormesh.cpp : 49
* egvtkobject.cpp : 857

In the Git version as of 23.11.2010 there are a lot more such regions....

2. Incorrect use of Templates.... This issue is of the form:


template <class T, uint_t N>
inline T SmallSquareMatrix<T,N>::det()
  // Determinant of the matrix
  // copy yourself to protect matrix entries
  SmallSquareMatrix<T,N> a = *this;

  int n=N;
  int k,i,j,p[n];

Here.... the variable p[n] is again an attempt to actually... dynamically allocate arrays in run-time like in the previous issue because "n" is a normal variable.... but what is actually intended here is I think:

p[N].... where "N" is the template variable which will be subsituted during compile time resulting in an array which is defined at compile-time rather than at run-time.

In engrid-1.2.0.tar you can find this in the following locations:
* smallsquarematrix.h : 253
* linsolve.h : 42

3. Use of "or" instead of "||"..... This issue is of the form:


    if ( minlen < 0 or len < minlen ) {
      minlen = len;
      id_minlen = id_node_neighbour;

In engrid-1.2.0.tar you can find this in the following locations:
* surfaceoperation.cpp : 633
* surfaceoperation.cpp : 656

Again.... if I remember right... there were more such similar constructs in the Git version (in the snapshot from 23.11.2010)

To re-iterate again.... this is not an attempt by me to try and point fingers at the engrid developers..... it was plainly surprising for me, that a frozen... released version of the code did not compile straight off.

I am definitely extremely interested in the software itself, because as you might realise, I am involved in the netgen development, and I find it really cool that you were able to integrate netgen into engrid and actually add features such as boundary layer generation....

Boundary layer generation was was something I tried to do in my spare time, but realised quickly that it was not something which can be "put-together" in my spare time.... and I was really excited when I saw the engrid functionality.

I spent over a week picking through the compiler errors one by one using the Git version, and fixing them one by one in my attempt to get it compiled before switching to the 1.2.0 version in the hope that it would compile faster.

Two days ago I finally managed to compile engrid on Windows with MSVC++ Express and Qt-4.7.1 ..... but when I try to open files in the GUI it always closes with a segmentation fault.... I assume that this is probably more to do with the different versions of Qt and VTK and the compiler itself which I am trying to use rather than something to do with the Engrid source code itself.

Once again.... sorry for the way I structured my post....

Have a great day ahead!


ogloth January 24, 2011 09:59


ok, now I understand your issues a bit better.

At the moment it is mainly me working on the code and I don't always push changes to SourceForge right away. On top of that, work had indeed stalled for a couple of weeks due to other projects.

I remember the array allocation issue now; it never compiled on windows in that form. Since there was virtually nobody asking for Windows support we didn't pay too much time on Windows compatibility, but you are right the code can, of course, be written differently -- with little extra effort. Having said that, I don't actually know what the C++ standard says about that kind of construction.

The 'or' statement you mentioned has disappeared in the current development line. To be honest, I was not aware of this form in the code; but I just looked and it seems to actually be allowed in the C++ standard.

The template error you mentioned seems to be an ancient work-around for some other kind of compiler problem. That bit of code has been used from a CFD code which started in the 90ies when templates were still cutting edge technology in C++.

Most people seem to be happy with just installing openSUSE or Ubuntu packages and all compilation related questions so far were related to Linux -- apart from one person who managed to compile it on MacOS.

Anyway, even if the code is standard compliant (which probably it is not) I have no problem to change it in a way that makes it compile on Windows without problems.

At the moment there are enough improvements for a new release but our project schedule doesn't really permit to work on that. Realistically I don't think we will have a new release before end of March or later. If you want, however, you can contact me any time and I can try to help you to get the current GIT master branch compiled on Windows.


wyldckat January 24, 2011 11:08

Greetings to all! Hi Philippose!

Oliver, let me introduce myself: my name is Bruno Santos and I work at blueCAPE in Portugal and we're a small company as well. We are responsible for the patches for cross-compiling OpenFOAM to Windows, made available here: Tip Cross Compiling OpenFOAM in Linux For Windows with MinGW - the binaries themselves we are distributing with our blueCFD product/service.

We've been planning on adding a few more open source applications to our blueCFD distribution, including those already ready to be used in Windows - e.g. FreeCAD and NETGEN - as well some that aren't readily available for Windows, namely enGrid 1.2.

So what can I (we at blueCAPE) do to help with the enGrid version for Windows?
Philippose, do you want to join efforts in helping out the git version of enGrid to keep to up-to-date to work in Windows?
Oliver, would it be best for us to open a separate git account somewhere else (perhaps at github or sourceforge) or can enGits provide external git branches for us to help you (I suppose at sourceforge)?

By the way, we also have experience in using Qt and VTK on our software development projects, compiling with both gcc+MinGW and MS Visual Express.

It felt best to follow the flow and keep this post public, instead of sending you both an email. This way, in case somebody else also wants to join in, feel free to drop us a line.

Best regards,

All times are GMT -4. The time now is 20:39.