Hi Ilteber,

I had a quick look into the XML file and indeed Nektar is giving you the correct message - There are no composites ( boundary flags) in the XML mesh. 

I can think of two main origins of the problem: 

• The way the mesh is generated in Gmsh does not assign boundary composites. 
• NekMesh InputGmsh.cpp conversion module is missing the boundary flags from the .msh file for the MeshFormat 4.1. 

I am not really familiar in details with the Gmsh file format, but we can schedule a quick meeting later this week to investigate it further. 

As far as I am aware, there are some Gmsh users in the Group, so I hope they can help you ensure that everything is correct on the Gmsh side.

Kind Regards,

Kaloyan 

---

From: nektar-users-bounces@imperial.ac.uk <nektar-users-bounces@imperial.ac.uk> on behalf of İlteber Özdemir <rilteber@gmail.com>
Sent: Monday, November 7, 2022 12:45 PM
To: nektar-users <nektar-users@imperial.ac.uk>
Subject: Re: [Nektar-users] Mesh Conversion from Gmsh using NekMesh

 

Hi again,

Is there anybody who can help me with this?

Kind regards,

Ilteber

--

İlteber R. Özdemir

On Wed, 2 Nov 2022 at 17:01, İlteber Özdemir <rilteber@gmail.com> wrote:

Hi Jeremy,

Thank you for your comments, they were very helpful. I was experimenting and realized that I have to define a Physical Surface in my script instead of a Plane Surface. That makes the difference. The mesh stats (No. of 2D elements) are indeed very close between gmsh and NekMesh, but I don't know where the difference stems from. Now NekMesh is able to convert and I can view the mesh using FieldConvert.

I have another problem though: IncNavierStokesSolver gives the following error:

Fatal   : Level 0 assertion violation
Composite not found.

So, there is something problematic with the mesh. I tried checking  the mesh using vtu, and it is alright. I also tried the xml:uncompress option in NekMesh and the resulting xml file seems OK. I would be happy if you can help me with this problem.

I attach the msh and xml files.

With kind regards,

Ilteber

--

İlteber R. Özdemir

On Sun, 30 Oct 2022 at 19:52, Jeremy Cohen <jeremy.cohen@imperial.ac.uk> wrote:

Hi Ilteber,

I’m not an expert on mesh files so hopefully another member of the community can offer more assistance but I did note that from the output you’re seeing, it’s looking like NekMesh’s “InputGmsh” reader is not understanding the file format that’s being provided as input because it doesn’t seem to actually be reading the mesh structure.

I wondered if this has something to do with the Gmsh file format you’re using. I tried some different Gmsh format versions and with ASCII V2, NekMesh does indeed seem to be able to read the mesh structure, however, it fails on writing the output, the same as you have below. You may already be familiar with this but you can export to a different Gmsh version by selecting File -> Export in Gmsh and then when you select to save the .msh file, it will give you options for the file version and a couple of other options (I have all unchecked in the version where NekMesh was able to read the mesh.

I’m seeing the following at the end of my outputs:

[InputGmsh]   Finished reading mesh.

[InputGmsh]    - Element dimension        : 2

[InputGmsh]    - Space dimension          : 2

[InputGmsh]    - No. of nodes             : 3264

[InputGmsh]    - No. of 2D elements       : 3116

[InputGmsh]    - No. of boundary elements : 305

[InputGmsh]     - Elapsed time: 0.226916s.

[OutputNekpp] Writing Nektar++ file 'out.xml'

Fatal   : Level 0 assertion violation

Unable to read composite index range: 

terminate called after throwing an instance of 'Nektar::ErrorUtil::NekError'

  what():  Level 0 assertion violation

Unable to read composite index range: 

The number of elements in the above matches the mesh statistics shown in Gmsh but the number of nodes seems far too low. I also see a huge number of warnings:

[InputGmsh]    -> Composite uses 

[InputGmsh]    -> Element uses   Q

[InputGmsh]   Have you specified physical volumes and surfaces?

[InputGmsh]   WARNING: Different types of elements in same composite!

From this, I’m assuming that there’s an issue with the composites in the mesh, especially given that NekMesh reports “Unable to read composite index range” when it tries to write out the Nektar XML file.

As I say, I’m not an expert on this but I hope this additional information is useful and maybe someone else can offer further advice.

Best wishes,

Jeremy

On 30 Oct 2022, at 15:25, İlteber Özdemir <rilteber@gmail.com> wrote:

This email from rilteber@gmail.com originates from outside Imperial. Do not click on links and attachments unless you recognise the sender. If you trust the sender, add them to your safe senders list to disable email stamping for this address.

 

Hi,

I am trying to convert a simple mesh made in Gmsh (cyl.msh) to Nektar++ usable format (.xml). I can view the mesh in Gmsh. NekMesh gives the following error when I try to convert:

NekMesh -v cyl.msh out.xml

[InputGmsh]   Reading Gmsh file: 'cyl.msh'
[InputGmsh]   Finished reading mesh.
[InputGmsh]    - Element dimension        : 0
[InputGmsh]    - Space dimension          : 2
[InputGmsh]    - No. of nodes             : 0
[InputGmsh]    - No. of 0D elements       : 0
[InputGmsh]    - No. of boundary elements : 0
[InputGmsh]     - Elapsed time: 0.0542657s.
[OutputNekpp] Writing Nektar++ file 'out.xml'
Fatal   : Level 0 assertion violation
Unable to read composite index range:
terminate called after throwing an instance of 'Nektar::ErrorUtil::NekError'
  what():  Level 0 assertion violation
Unable to read composite index range:
Aborted

Can you help me with this problem? 

With kind regards,

Ilteber

--

İlteber R. Özdemir

<cyl.msh>_______________________________________________
Nektar-users mailing list
Nektar-users@imperial.ac.uk
https://mailman.ic.ac.uk/mailman/listinfo/nektar-users