Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Sign In Apply for Membership

Export from Blender
  • paul May 2010
    Hi Mike and Oliver,

    I just tried out the export script and encountered a problem. This is what I did: I imported a simple geometry (stl) into blender, scaled it down with factor 0.001, manually remeshed it and put a cube around it to generate the outer boundary of the fluid domain. When I import this into blender using the script the cube shows up in its desired size but the former stl geometry turns out to be in its original size, i.e. without the scaling i did in blender.
    Maybe its just me not knowing to scale this properly in blender, so I would appreciate if you could have a short look at the blender and begc files please!

    Thanks a lot and best regards,
    Paul
  • Oliver May 2010
    Hi Paul,

    I had a look at your Blender model and there are a few things to watch out for:

    [list]
    [*] Try to make all modifications in edit-mode not in object mode. Currently the export script exports the non-transformed coordinates; you can apply transformations in object mode but they will not be picked up by the export script. You can, however, apply transformations in object mode and accept them later by pressing <Ctrl-A>. Another pitfall are translations in object mode (Loc X, Loc Y, Loc Z in the transform properties window). These, as far as I know, will not be picked up by the export script either and they cannot be accepted with <Ctrl-A>. A way around this is to place all objects at the same position (e.g. 0,0,0) and move them in edit mode. We will probably change the export script to reflect what you actually see on the screen, but for now those workarounds should do.[/*:m]
    [*] The model in Blender should be water-tight.[/*:m][/list:u]

    To get a water-tight model I follow this procedure:
    [list]
    [*] Build a water-tight model with one object only. You can check if the model is water-tight by using "Select->Non-Manifold" in Blender's edit mode.[/*:m]
    [*] Make sure you have only triangles and no quads by pressing <Ctrl-T>.[/*:m]
    [*] Orient all normal vectors to the outside by pressing <Ctrl-N>.[/*:m]
    [*] Define boundary conditions by splitting the model.[/*:m][/list:u]

    Sometimes it can be useful to export the model to enGrid before defining the boundaries. In enGrid do a fix CAD geometry and export back to Blender. This step is not normally required but it can help to avoid bad triangles in the geometry.

    I have attached a few files to illustrate what I mean:
    [list]
    [*] Wing2_S0.blend: A water-tight Blender model with the symmetry joined to the root of the wing.[/*:m]
    [*] Wing2_S1.blend: The same model with boundary definitions. I have split the wing into 8 instead of 4 sections in order to have a different resolution for the leading and trailing edge.[/*:m]
    [*] Wing2_S1.egc: An example enGrid case, showing how this model could be set up for meshing.[/*:m]
    [*] Wing2_S1.egc.vtu: The corresponding grid file.[/*:m][/list:u]

    I hope this helps!

    Best regards,
    Oliver
  • Mike May 2010
    Workaround to get all objects scaled, rotated and placed the same way:
    1) Go into object mode
    2) Select all objects you wish to export in Blender
    3) Object->Clear/Apply -> Apply Scale/Rotation to ObData (ctrl-A,1)
    4) Panels->Editing (F9)
    5) In the mesh window, click "Center cursor"
    6) Export as .begc

    You can use Object->Transform properties (N) to check the current object properties.
  • paul May 2010
    The ctrl-A trick did it.

    Thanks a lot for clearing this up!
    And also special thanks to you, Oliver, for explaining how to use blender for modelling at the openfoam meeting last week :)


    Best regards,
    Paul
  • paul May 2010
    One more question just came up:
    if I add a set in the surface mesh settings dialog the set is generated and all the checkboxes for the individual bc's show up. For each checkbox there exist three states: checked, not checked and marked (in Ubuntu it is colored brown). Does the marked state have any influence on the meshing or can it be ignored?

    Thanks and best regards,
    Paul
  • paul May 2010
    Ok, after some testing I found out that the colored check boxes don't have an influence on the meshing as far as i noticed.
    Another question regarding the surface mesh:
    What does the cell growth factor do? I played around with it but from the results I was not able to come up with a general idea of what it does. It seemed to have influence on how the surface mesh cell size propagates from the edge into the middle of the surface. But for different geometries I had to set different factors even though the edge length was the same.

    So, what is it for?

    Thanks a lot and best regards,
    Paul
  • Oliver May 2010
    The cell(edge)-size is determined with the following strategy:
    [list]
    [*] Every node has a maximal edge-length attached to it; it can either be defined with the help of the check-boxes, or simply is the maximal length specified in the dialogue. (For the next release I think we need a somewhat more user-friendly way to define the rules, because with 40 boundary patches it can become quite tedious.)[/*:m]
    [*] Initially all nodes are set to the minimal edge length that has been defined.[/*:m]
    [*] Starting from the nodes with the smallest defined edge-length the neighbours are set to an edge length that is "cell growth factor" times bigger than the small length. If you are interested the code for this can be found in updatedesiredmeshdensity.cpp (lines 182-219).[/*:m][/list:u]
    I hope this shed some light on the process. Basically a higher value for the growth factor will result in a quicker transition from fine to coarse regions. The actual size cannot be defined by the growth factor. If you have a geometry that gives some weird results, please post it to the forum and I'll have a look.

    Cheers,
    Oliver
  • paul May 2010
    Ok, thanks for clearing this up. I think I understand the concept but nevertheless, in my last case I had to use cell growth factors of 100-1000 to get a surface mesh with evenly distributed cells, which seems a bit strange to me. Shouldn't the cgf be around 1 if I want a mesh with cells of the same size?

    However, another thing just came up and maybe this time its not me doing stupid things but a bug:
    If I take the standard cube that comes with every new blender file, subdivide the surfaces several times, separate it nicely into different boundary faces and import into engrid to get and empty fluid domain, everything works nicely. The prism layer is created on the inside just as it should be. But if I take that cube, enclose it into another, bigger cube to get a channel with a cube-like body inside, the volume mesh generation crashes just after the prism layer is seeded. The boundary codes are properly defined, the mesh is watertight and consisting only of triangle elements. The geometry is attached. The error message I get is:

    image

    The prism layer is generated but it is very "rough" as you can see here (clipping enabled):

    image

    Also the surface mesh of the outer box is distorted a little bit next to the inner cube.
    However, if I click the prism layer generation button again, check "Improve layer" and un-check "Remove points" (what is this btw?) the tet-mesh is generated but most of the prism layer is missing:

    image

    I hope you guys can fix this and that it's not me missing something essential.
    Have a good holiday!
    Paul
  • Oliver May 2010
    Hi,

    I think I know what it is; there is a work-around, but before I go into a lengthy explanation I will check it it actually works -- I'll let you know on Friday. You said that you had to use cgf of 100 to get a proper node distribution ... could you please send me the case file (or post it on the forum) and I have a look. If you want an evenly distributed mesh, simply set the mesh size for that patch with the rules.

    The "remove points" option specifies if enGrid is allowed to remove nodes from boundary patches that intersect the boundary layer (e.g. a symmetry plane). In your case there is no such boundary and hence you get this stupid error. That is a bug, but to uncheck the box prevents it and has no negative impact.

    Cheers,
    Oliver
  • paul May 2010
    Hey Oliver,

    sorry for the delay!
    I just experienced the "I have to set the CGF to 100" case again.
    Two screenshots, the first with CGF = 1.5, the second with CGF = 100:

    image

    image

    One more thing regarding the Sets used for surface meshing:
    The surface mesh degenerates if no rule set is used. Example:
    I have a sphere (the one from the images above). I thought I could simply set the Maximum edge length to what ever I like (0.05 in this case) and it would mesh anything selected in the list above with this characteristic length. But unless I specify a set which forces the same edge length, the mesh degenerates.

    Two screenshots, the first showing the surface parameter dialog box. The set specified on the left has the same purpose as the Maximum edge length text box.
    image

    If this is NOT done, i.e. if the set is removed, the mesh turns into this:
    image

    This means that I have to specify a set for every edge, which might be a bit boring concidering complex geometries. Is this intentional, i.e. does it offer advantages that I just don't see?

    Best regards,
    Paul

    ps: I'm just writing a tutorial on Blender and Engrid. If you like I could send it to you, maybe on Friday...
  • paul May 2010
    Forgot to attach the files...
  • Oliver May 2010
    Hi Paul,

    just a quick answer, because I am quite busy at the moment.

    The behaviour if you have no setting at all (just the maximal cell size) is a bug. As soon as you have one setting it will work and the the maximal cell size will be respected on all surfaces. The whole settings mechanism isn't too intuitive and it will be changed again (suggestions welcome!).

    A tutorial would be most appreciated :D By all means, send it over (by email) and I'll have a look.

    Thanks,
    Oliver
  • paul June 2010
    Hi Oliver,
    sorry for not responding for so long, I have been busy doing other stuff. The tutorial is going to be in your mailbox on monday...

    Another question just came up: I am extruding the prism layer around a wing. First I tried it with a very sharp trailing edge (around 10°) and the result was not very nice in terms of aspect ratio and orthogonality. I guess thats just a thing that is not easy to mesh. However, I now use a blunt trailing edge now and everything works fine except for one error: the wing is made of an inner and an outer part and both parts consist of a suction- and a pressure side patch. In the middle of the wing span, where the outer and inner sections meet, the prism layer is not extruded properly:

    image

    The underlying surface mesh looks like this:

    image

    Initially I had several of those errors along the trailing edge but after around a hundred iterations and increasing the number of layer height relaxations, normal vector relaxations, pre-steps, smoothing steps and smoothing sub iterations I could get rid of all of them except for the last one.

    Would you know why this happens and how it could be done properly?


    Thanks and best regards,
    Paul
  • Oliver June 2010
    Hi Paul,

    meshing a wing with a sharp trailing edge should be OK in my opinion -- actually it would be my preferred solution unless you are interested in the vortex shedding of the trailing edge. Did you try to run something on the grid -- despite the non-orthogonality and skewness errors. It would be interesting to have a comparison between sharp and blunt trailing edge (drag and lift coefficient); a sharp trailing edge would significantly reduce the number of cells.

    Having said all that, the blunt trailing edge has to work; could you please send the geometry over by email? I remember having something similar as well, but I forgot what caused it.

    Regards,
    Oliver
  • paul June 2010
    Hi Oliver,

    thanks for the quick reply! I sent you the grid. I did'nt really check the sharp trailing edge mesh or try to run anything, it just looked unhealthy... But that was before I saw all the relaxation and smoothing parameters. I'll try it again with setting them to higher values.

    BEst regards,
    Paul
  • Oliver June 2010
    Paul,

    I re-created the boundary layer and got the same problems, until I realised that I was still using 1.2rc4 instead of 1.2.0 as "stable" installation. With 1.2.0 the mesh looks a lot better, so you might want to give it a try. Btw., why is the wing detached from the symmetry plane??

    Regards,
    Oliver
  • paul June 2010
    Hi Oliver,

    thanks a lot! I thought that the update to 1.2.0 would somehow happen through the Ubuntu update manager... Are there going to be binaries for debian systems? For now I'll try the install scripts.
    The wing is detached from the base as I am going to move it in a bird-like flapping motion which features strong rotation around the span-wise axis. It is easier to keep the mesh valid throughout the stroke if the wing is detached from the channel walls.

    I'll let you know about the prism layer tomorrow!

    Best regards,
    Paul
  • Oliver June 2010
    Hi Paul,

    unfortunately Mike moved to the UK to become a PhD student. I tried to chain him to his office chair, but the police forced me to let him go. Seriously, there is nobody taking care of the Debian/Ubuntu packages at the moment. I have zero experience with Debian packaging. If you know somebody who could do that -- great ;-)

    Anyway, if you have installed one of the existing packages, all dependencies should be there. Hence I assume it would be fairly easy to get the source code from GIT and compile it. Usually the dependencies causes all the compilation headache.

    Cheers,
    Oliver
  • paul June 2010
    Hi Oliver,

    I managed to compile 1.2.0 using the install script. Unfortunately the trailing edge error persists in both, the single and the divided trailing edge. Any ideas?

    Another thing regarding the cell growth factor issue that I mentioned some posts above: I tried some different configurations and found the following:
    1.Cell growth factor (CGF) 1.5, maximal edge length (MEL) 0.02, no set ==> as many faces as possible are removed, e.g. a cube would have two triangle faces on each side.
    2. CGF 1.5, MEL 0.02, one set added but no edge selected within that set and no edge length specified in the set (i.e. -1) ==> more and more cells are added, the number of added nodes doubles with every iteration
    3. CGF 1.5, MEL 0.02, one set added, no edge selected within that set and edge length set to 0.02 ==> works fine
    4. CGF 1.5, MEL 0.02, one set added, one edge selected within that set and edge length set to 0.02 ==> the selected edge is meshed fine but in the surrounding mesh as many cells as possible are removed.
    5. CGF 1.5, MEL 0.02, one set for every edge, edge length of 0.02 ==> the mesh along the edges is fine but becomes very coarse towards the middle of the individual patches.
    6. CGF 1000, MEL, 0.02 one set for every edge, edge length of 0.02 ==> works fine.

    Maybe this is helpful for improving the program and for other users!


    Best regards,
    Paul
  • I am having an error at a patch boundary I seem unable to eliminate. It is a surface mesh issue, but it reminds me of the volume mesh issue Paul mentions above. I cannot figure out how to post images here, so please see video: http://screencast.com/t/isTrpKBmt

    Any comments appreciated.

    Thanks,
    Karl
  • wyldckat July 2012
    Hi Karl,

    I'm unable to watch your screencast, due to network issues on my side.
    Nonetheless, it looks like you're triggering this bug: http://sourceforge.net/apps/mantisbt/engrid/view.php?id=14
    See "Additional Information" on how to go around the issue.

    Best regards,
    Bruno
  • Thanks Bruno; it was more of a height relaxation error at the boundary I think (not sure if that is proper terminology but that is what it looks like to me as the height of the surface appears to not adjust at the border of the patch). I downloaded the development branch to my Linux installation last night and the problem seems to have gone away; I was working on the June 17 Win64 version before. I won't know for another few hours as it is still meshing. Regards, K
  • OK, so the remesh showed the same problem. I will try adjusting the under relaxation parameter. Ultimately I may need to go back and generate a higher resolution stl file if I can not sort this out.
  • wyldckat July 2012
    Hi Karl,

    I saw the other day this comment:
    This was fixed by transforming / scaling the mesh by factor 1000 from within Engrid. The mesh was created and scaled back at the end. :) 

    Source: http://engits.eu/vanilla/index.php?p=/discussion/282/netgen-stopped-with-the-following-error-illegal-state-observed-in-swapimprove/

    Best regards,
    Bruno
  • Thanks Bruno I saw that and have already tried it - no difference for my geometry; it just forces me to re-do all the meshing parameters for the new size and comes out looking the same. For the 3D mesh it might make a difference, but not for this surface mesh.

    For whatever reason, it is not smoothing the edge of the patch. I tried a lot of smoothing; just now it is set up to do 20 iterations with 20 smoothing steps per iteration, but I suspect it may not help as there has been little change with many iterations. Ultimately I may need a higher quality .stl file, which is no problem to generate fundamentally. I am just surprised I cannot get this surface issue to smooth out.
  • wyldckat July 2012
    Hi Karl,

    OK, so I took another look at the presentation and here's a question and a possible issue that I know of:
    Question: do those zones that you're trying to smooth out, in the same boundary code? If not, that's the reason why the edges/obstacles are being preserved.

    Known issue: https://github.com/enGits/engrid/issues/16 - there is an advanced option of "minimal number of cells across" that will override some of the surface meshing rules. So try setting that value higher than 0.

    Best regards,
    Bruno
  • atypicalguy September 2012
    Thanks Bruno. I tried that without benefit. But I did succeed eventually by fixing the stl.

    This was just due to poor resolution in the stl file. The trouble spots were originally long edges in the file. I reduced the maximum aspect ratio of the stl faces and this fixed the problem. I think the algorithm cannot smooth spanwise across the high aspect ratio cells, for whatever reason - it is obviously a compound curve and it was treating those long edges as reference points on the surface, rather than trying to break them into smaller segments and smooth them spanwise.