Hi both, Just as a quick followup, I do seem to remember there being an issue with spherigons being defined on multiple surfaces at some point, although precisely when escapes memory at the moment. You might try, on the latest development version of the code using: -m spherigon:surf=7,8,9 instead. You could also double check which surfaces are being curved with: MeshConvert -m extract:surf=7 input.xml surf-7.xml which produces the surface 7 XML file that can be visualised with XmlToVtk. Cheers, Dave On 1 Apr 2015, at 16:22, Sherwin, Spencer J <s.sherwin@imperial.ac.uk> wrote:
Hi Kamil,
I do not know what is going on in the first case. This would seem to be that it does not think you have surfaces 7,8,9 defined in your input file. Are these composites defined with ids=7,8,9
With regard to point 2 this is a challenge of high order mesh generation. Essentially it is telling you that when you have deformed the elements you get an invalid element where the surface curvature is self intersecting the element and therefore making the Jacobian of the element go to zero. In this case you usually have to reduce the surface curvature to help alleviate this issue.
Cheers, Spencer.
On 31 Mar 2015, at 13:44, Kamil ÖZDEN <kamil.ozden.me@gmail.com> wrote:
Dear All,
I've tried spherigon patches both with meshes consisting of prism+tetra elements and only tetra elements. In both of them it worked and gave me curved edges. However, there are two issues that I want to mention:
1) When I wrote the command below to use spherigon patches
./MeshConvert -m spherigon:surf=7 -m spherigon:surf=8 -m spherigon:surf=9 V_F_Mesh2.xml V_F_Mesh2_spherigon.xml
I got such a message:
WARNING: Spherigon surfaces have not been defined -- ignoring smoothing.
2) When I want to get paraview file to check the mesh by writing
./XmlToVtk V_F_Mesh2_spherigon.xml V_F_Mesh2_spherigon.vtu
I got such a message for a few elements:
Warning: Level 0 assertion violation 3D deformed Jacobian not positive (element ID = 5723) (first vertex ID = 1409)
But I don't get this message when I convert the original .xml file to paraview file (V_F_Mesh2.xml --> the one before using spherigon patches).
I think this issue may lead to problems in my analyses. How can I overcome this problem?
Thanks...
Best Regards, Kamil
On 16.03.2015 14:20, Kamil ÖZDEN wrote:
Dear All,
I found such a way to generate my meshes to use in Nektar++:
1) First I create my mesh in ICEM CFD. 2) Then I export that mesh from ICEM CFD as a Nastran file (with *.dat extension). 3) After that I open that *.dat file in Gmsh and save it as a *.msh file. 4) Finally I generate my *.xml file from that *.msh file.
This works in Nektar++ but I have a problem about generating curved edges in ICEM CFD. There is no such option or I couldn't find how to succeed this. Is there any one who use this method to generate mesh for Nektar or can inform me about generating high order edge in ICEM CFD?
NOTE: I've tried to generate curved edge in Gmsh with the imported *.dat file but it didn't work.
Regards, Kamil
_______________________________________________ Nektar-users mailing list Nektar-users@imperial.ac.uk https://mailman.ic.ac.uk/mailman/listinfo/nektar-users
Spencer Sherwin McLaren Racing/Royal Academy of Engineering Research Chair, Professor of Computational Fluid Mechanics, Department of Aeronautics, Imperial College London South Kensington Campus London SW7 2AZ
s.sherwin@imperial.ac.uk +44 (0) 20 759 45052
_______________________________________________ Nektar-users mailing list Nektar-users@imperial.ac.uk https://mailman.ic.ac.uk/mailman/listinfo/nektar-users
-- David Moxey (Research Associate) d.moxey@imperial.ac.uk | www.imperial.ac.uk/people/d.moxey Room 363, Department of Aeronautics, Imperial College London, London, SW7 2AZ, UK.