Re: [Nektar-users] Transferring curved edge information to Nektar++
Dear All, Regarding my previous question I found that there is an option in Gmsh to get higher order elements for reflecting curvature of the edges into .xml file. However, when I increase the order of the element from 1 to a higher order (e.g. 3) and convert the .xml file to .vtu file I got the message: /*Warning: Level 0 assertion violation*//* *//*3D deformed Jacobian not positive (element ID = 359) (first vertex ID = 206)*/ and the mesh that MeshConvert obtained from Gmsh's .msh file looks like: As far as I know "Jacobian not positive" means there are intersecting elements. What may be the reason for this problem? Regards, Kamil On 18-09-2014 11:36, Kamil Ozden wrote:
Dear All,
I mesh a circular pipe in Gmsh very coarsely as below and turn it into a xml file via MeshConvert. However, the curved edge information is not transferred to the xml file (as seen in the figure at right). How can I succeed this? Is there any way of doing it in Gmsh or is this directly related with Nektar++ ?
Hi Kamil, This is a known bug that we still need to address. In the XML file there is a <CURVED> section which stores the curvature information. If you remove all lines that begin with <F ID="..." FACEID="..." ... </F> the mesh should convert and you should obtain a curved mesh. What happens here is that gmsh supplies face-interior curvature, which presently is not reordered correctly, causing intersecting elements. However edge curvature will still work, and this will be blended onto the interior of the element by our basis functions. Whenever I get a chance I'll try to patch this issue as it's not really ideal! Thanks, Dave On 22 Sep 2014, at 08:46, Kamil Ozden <kamil.ozden.me@gmail.com> wrote:
Dear All,
Regarding my previous question I found that there is an option in Gmsh to get higher order elements for reflecting curvature of the edges into .xml file. However, when I increase the order of the element from 1 to a higher order (e.g. 3) and convert the .xml file to .vtu file I got the message:
Warning: Level 0 assertion violation 3D deformed Jacobian not positive (element ID = 359) (first vertex ID = 206)
and the mesh that MeshConvert obtained from Gmsh's .msh file looks like:
<biabjfca.png>
As far as I know "Jacobian not positive" means there are intersecting elements. What may be the reason for this problem?
Regards, Kamil
On 18-09-2014 11:36, Kamil Ozden wrote:
Dear All,
I mesh a circular pipe in Gmsh very coarsely as below and turn it into a xml file via MeshConvert. However, the curved edge information is not transferred to the xml file (as seen in the figure at right). How can I succeed this? Is there any way of doing it in Gmsh or is this directly related with Nektar++ ?
_______________________________________________ Nektar-users mailing list Nektar-users@imperial.ac.uk https://mailman.ic.ac.uk/mailman/listinfo/nektar-users
Dear Dr. Moxey, Thank you, this correction solved my problem. I've an additional question now. When converting .msh file to .xml file by using a higher order element, MeshConvert directly converts the mesh with the /*TYPE="PolyEvenlySpaced"*/ in <CURVED> section. How can I change this to /*TYPE="GaussLobattoLegendre" */?/* */Regards, Kamil On 22-09-2014 10:57, David Moxey wrote:
Hi Kamil,
This is a known bug that we still need to address. In the XML file there is a <CURVED> section which stores the curvature information. If you remove all lines that begin with <F ID="..." FACEID="..." ... </F> the mesh should convert and you should obtain a curved mesh.
What happens here is that gmsh supplies face-interior curvature, which presently is not reordered correctly, causing intersecting elements. However edge curvature will still work, and this will be blended onto the interior of the element by our basis functions. Whenever I get a chance I'll try to patch this issue as it's not really ideal!
Thanks,
Dave
Dear All, I asked the question below to check an important issue. This is a reminder mail. Is there any way to succeed to change /*TYPE="PolyEvenlySpaced" */to /*TYPE="GaussLobattoLegendre" */when converting the msh to xml via MeshConvert? Regards, Kamil On 23-09-2014 15:50, Kamil Ozden wrote:
Dear Dr. Moxey,
Thank you, this correction solved my problem. I've an additional question now.
When converting .msh file to .xml file by using a higher order element, MeshConvert directly converts the mesh with the /*TYPE="PolyEvenlySpaced"*/ in <CURVED> section. How can I change this to /*TYPE="GaussLobattoLegendre" */?/*
*/Regards, Kamil
On 22-09-2014 10:57, David Moxey wrote:
Hi Kamil,
This is a known bug that we still need to address. In the XML file there is a <CURVED> section which stores the curvature information. If you remove all lines that begin with <F ID="..." FACEID="..." ... </F> the mesh should convert and you should obtain a curved mesh.
What happens here is that gmsh supplies face-interior curvature, which presently is not reordered correctly, causing intersecting elements. However edge curvature will still work, and this will be blended onto the interior of the element by our basis functions. Whenever I get a chance I'll try to patch this issue as it's not really ideal!
Thanks,
Dave
Dear Kamil, The CURVED section is describing the geometric curvature of the elements, and the PolyEvenlySpaced describes the point distribution used to represent this curvature. This is used because it is the point distribution produced by GMsh. This distribution is unrelated to the basis and point distribution used to represent the PDE solution within Nektar++. There is no way at present to represent the geometric curvature using a different point distribution. Kind regards, Chris On 29/09/14 08:54, Kamil Ozden wrote:
Dear All,
I asked the question below to check an important issue. This is a reminder mail. Is there any way to succeed to change /*TYPE="PolyEvenlySpaced" */to /*TYPE="GaussLobattoLegendre" */when converting the msh to xml via MeshConvert?
Regards, Kamil
On 23-09-2014 15:50, Kamil Ozden wrote:
Dear Dr. Moxey,
Thank you, this correction solved my problem. I've an additional question now.
When converting .msh file to .xml file by using a higher order element, MeshConvert directly converts the mesh with the /*TYPE="PolyEvenlySpaced"*/ in <CURVED> section. How can I change this to /*TYPE="GaussLobattoLegendre" */?/*
*/Regards, Kamil
On 22-09-2014 10:57, David Moxey wrote:
Hi Kamil,
This is a known bug that we still need to address. In the XML file there is a <CURVED> section which stores the curvature information. If you remove all lines that begin with <F ID="..." FACEID="..." ... </F> the mesh should convert and you should obtain a curved mesh.
What happens here is that gmsh supplies face-interior curvature, which presently is not reordered correctly, causing intersecting elements. However edge curvature will still work, and this will be blended onto the interior of the element by our basis functions. Whenever I get a chance I'll try to patch this issue as it's not really ideal!
Thanks,
Dave
_______________________________________________ Nektar-users mailing list Nektar-users@imperial.ac.uk https://mailman.ic.ac.uk/mailman/listinfo/nektar-users
-- Chris Cantwell Department of Aeronautics Roderic Hill Building Imperial College London South Kensington Campus London SW7 2AZ Email: c.cantwell@imperial.ac.uk www.imperial.ac.uk/people/c.cantwell
Hi Dr. Cantwell, As far as I understood from your answer it is not possible to obtain another point distribution except PolyEvenlySpaced via Gmsh. I wonder that how did you obtain the GaussLobattoLegendre point distribution in your /*Turbulent Pipe Flow Quasi-3D*/ solution. With a mesh generator other than Gmsh? Regards, Kamil 02.10.2014 17:59 tarihinde, Chris Cantwell yazd?:
Dear Kamil,
The CURVED section is describing the geometric curvature of the elements, and the PolyEvenlySpaced describes the point distribution used to represent this curvature. This is used because it is the point distribution produced by GMsh. This distribution is unrelated to the basis and point distribution used to represent the PDE solution within Nektar++.
There is no way at present to represent the geometric curvature using a different point distribution.
Kind regards, Chris
_______________________________________________ Nektar-users mailing list Nektar-users@imperial.ac.uk https://mailman.ic.ac.uk/mailman/listinfo/nektar-users
participants (4)
-
Chris Cantwell
-
David Moxey
-
Kamil Ozden
-
Kamil ÖZDEN