Add Nastran backend by bayswiss · Pull Request #46 · scientificcomputing/io4dolfinx

bayswiss · 2026-05-06T16:04:49Z

Status: Draft - opening for early feedback before adding tests.

Refers #43

Tested manually outside the repo against multiple nastran meshes generated with different commercial preprocessors.

Before polishing I'd like input on where Nastran test inputs should live and what level of testing is needed. Do I commit a small bdf and run a test similar to "test_pyvista.py"?

for more information, see https://pre-commit.ci

jorgensd · 2026-05-12T11:11:28Z

+ if not topologies:
+ raise ValueError(f"No elements found in {filename}.")
+
+ elements = []


Maybe a comment here that explains that the main purpose of everything up to Line 329 is to sanity check that we have extracted some elements of a given cell type with a given name.

I will add that

jorgensd · 2026-05-12T11:12:11Z

+ elements = []
+ for gmsh_type in topologies:
+ _, dim, _, n_nodes, *_ = gmsh.model.mesh.getElementProperties(gmsh_type)
+ elements.append((dim, n_nodes, gmsh_type))
+
+ dims = [e[0] for e in elements]
+ if len(dims) != len(set(dims)):
+ raise ValueError(
+ f"Multiple element types share a topological dimension in {filename}."
+ )
+ _, num_nodes, gmsh_type = max(elements, key=lambda e: e[0])


I guess this is also mainly for error handling/sanity checking perspective?

Yes. Nastran mixed meshes (hexa-pyramid-tetra) are very common in some commercial preprocessors

We could add support for these kinds of meshes, as they are supported in DOLFINx, albeit the interface is very rough. If you have a link to a mixed type mesh I can have a go at improving your API.

jorgensd · 2026-05-12T11:13:02Z

I think this is a good start. I guess the optimal thing would be to have the nastran grids stored somewhere else (like Zenodo) and fetch them if they are not present on the system. @finsberg what do you think?

finsberg · 2026-05-12T14:38:51Z

I think this is a good start. I guess the optimal thing would be to have the nastran grids stored somewhere else (like Zenodo) and fetch them if they are not present on the system. @finsberg what do you think?

Nice work @bayswiss. I think this looks very good. Having a test in place where we can test on some real meshes would be good. Perhaps we can just grab some of the meshes from this repo: https://github.com/SteveDoyle2/pyNastran/tree/main/models ?

bayswiss · 2026-05-12T14:46:12Z

I think this is a good start. I guess the optimal thing would be to have the nastran grids stored somewhere else (like Zenodo) and fetch them if they are not present on the system. @finsberg what do you think?
Nice work @bayswiss. I think this looks very good. Having a test in place where we can test on some real meshes would be good. Perhaps we can just grab some of the meshes from this repo: https://github.com/SteveDoyle2/pyNastran/tree/main/models ?

Thank you @finsberg. I will check 'em out, since pynastran handles complete nastran decks (that contain also simulation instructions). If not present, I can provide a basic one.
Is a test similar to the pyvista one fine?

finsberg · 2026-05-12T15:27:49Z

I think this is a good start. I guess the optimal thing would be to have the nastran grids stored somewhere else (like Zenodo) and fetch them if they are not present on the system. @finsberg what do you think?
Nice work @bayswiss. I think this looks very good. Having a test in place where we can test on some real meshes would be good. Perhaps we can just grab some of the meshes from this repo: https://github.com/SteveDoyle2/pyNastran/tree/main/models ?
Thank you @finsberg. I will check 'em out, since pynastran handles complete nastran decks (that contain also simulation instructions). If not present, I can provide a basic one. Is a test similar to the pyvista one fine?

A simliar test as the pyvista one if fine. The most important thing is to have a test in place that tests the basic functionality. I don't know if there are a lot of variations in nastran files, but might be good to have some tests that covers the common scenarios. For example if mixed cell types are common it is good to have test for that.

It is also possible to add a step in in the test_workflow.yml which can download the data used by the tests. Whether this is from another repository (like pynastran) or Zenodo doesn't really matter.

bayswiss · 2026-05-12T15:52:53Z

A simliar test as the pyvista one if fine. The most important thing is to have a test in place that tests the basic functionality. I don't know if there are a lot of variations in nastran files, but might be good to have some tests that covers the common scenarios. For example if mixed cell types are common it is good to have test for that.
It is also possible to add a step in in the test_workflow.yml which can download the data used by the tests. Whether this is from another repository (like pynastran) or Zenodo doesn't really matter.

I will start working on the basic test. Regarding mixed meshes, what am I missing? is dolfinx going to support them soon (I am on 0.10.0 currently)?

jorgensd · 2026-05-14T20:12:59Z

A simliar test as the pyvista one if fine. The most important thing is to have a test in place that tests the basic functionality. I don't know if there are a lot of variations in nastran files, but might be good to have some tests that covers the common scenarios. For example if mixed cell types are common it is good to have test for that.
It is also possible to add a step in in the test_workflow.yml which can download the data used by the tests. Whether this is from another repository (like pynastran) or Zenodo doesn't really matter.
I will start working on the basic test. Regarding mixed meshes, what am I missing? is dolfinx going to support them soon (I am on 0.10.0 currently)?

There is already partial support for mixed meshes. The PR I opened today makes it possible to read those meshes from gmsh: FEniCS/dolfinx#4214

bayswiss · 2026-05-15T13:34:38Z

@jorgensd Sorry for the slow reply. Here's an example of what is sometimes called a "hexcore" mesh:
hexacore.zip

The idea is to fill the bulk of the domain with a Cartesian hex grid and use tets only near the boundary to handle geometric complexity, with pyramids as transition elements. The appeal is getting most of the numerical benefits of a structured hex mesh without actually having to build one.

One concern for wave propagation applications: the hex-pyramid-tet interface introduces a local change in dispersion characteristics, which can act as a weak spurious reflector. Not a dealbreaker, but worth keeping in mind depending on the frequency range (I actually don't use it but I've seen it a lot).

P.S. The parallelepiped is just to show the element structure, obviously nobody would use a mixed mesh approach on a geometry this simple.

jorgensd · 2026-05-15T14:07:56Z

@jorgensd Sorry for the slow reply. Here's an example of what is sometimes called a "hexcore" mesh:
hexacore.zip
The idea is to fill the bulk of the domain with a Cartesian hex grid and use tets only near the boundary to handle geometric complexity, with pyramids as transition elements. The appeal is getting most of the numerical benefits of a structured hex mesh without actually having to build one.
One concern for wave propagation applications: the hex-pyramid-tet interface introduces a local change dispersion characteristics, which can act as a weak spurious reflector. Not a dealbreaker, but worth keeping in mind depending on the frequency range (I actually don't use it but I've seen it a lot).
P.S. The parallelepiped is just to show the element structure, obviously nobody would use a mixed mesh approach on a geometry this simple.

No worries, as you see, there were some missing pieces in the gmshio code to read such meshes, which should hopefully be resolved with my PR.

bayswiss · 2026-05-06T16:04:49Z

Status: Draft - opening for early feedback before adding tests.

Refers #43

Tested manually outside the repo against multiple nastran meshes generated with different commercial preprocessors.

Before polishing I'd like input on where Nastran test inputs should live and what level of testing is needed. Do I commit a small bdf and run a test similar to "test_pyvista.py"?

for more information, see https://pre-commit.ci

jorgensd · 2026-05-12T11:11:28Z

+ if not topologies:
+ raise ValueError(f"No elements found in {filename}.")
+
+ elements = []


Maybe a comment here that explains that the main purpose of everything up to Line 329 is to sanity check that we have extracted some elements of a given cell type with a given name.

I will add that

jorgensd · 2026-05-12T11:12:11Z

+ elements = []
+ for gmsh_type in topologies:
+ _, dim, _, n_nodes, *_ = gmsh.model.mesh.getElementProperties(gmsh_type)
+ elements.append((dim, n_nodes, gmsh_type))
+
+ dims = [e[0] for e in elements]
+ if len(dims) != len(set(dims)):
+ raise ValueError(
+ f"Multiple element types share a topological dimension in {filename}."
+ )
+ _, num_nodes, gmsh_type = max(elements, key=lambda e: e[0])


I guess this is also mainly for error handling/sanity checking perspective?

Yes. Nastran mixed meshes (hexa-pyramid-tetra) are very common in some commercial preprocessors

We could add support for these kinds of meshes, as they are supported in DOLFINx, albeit the interface is very rough. If you have a link to a mixed type mesh I can have a go at improving your API.

jorgensd · 2026-05-12T11:13:02Z

I think this is a good start. I guess the optimal thing would be to have the nastran grids stored somewhere else (like Zenodo) and fetch them if they are not present on the system. @finsberg what do you think?

finsberg · 2026-05-12T14:38:51Z

I think this is a good start. I guess the optimal thing would be to have the nastran grids stored somewhere else (like Zenodo) and fetch them if they are not present on the system. @finsberg what do you think?

Nice work @bayswiss. I think this looks very good. Having a test in place where we can test on some real meshes would be good. Perhaps we can just grab some of the meshes from this repo: https://github.com/SteveDoyle2/pyNastran/tree/main/models ?

bayswiss · 2026-05-12T14:46:12Z

I think this is a good start. I guess the optimal thing would be to have the nastran grids stored somewhere else (like Zenodo) and fetch them if they are not present on the system. @finsberg what do you think?
Nice work @bayswiss. I think this looks very good. Having a test in place where we can test on some real meshes would be good. Perhaps we can just grab some of the meshes from this repo: https://github.com/SteveDoyle2/pyNastran/tree/main/models ?

Thank you @finsberg. I will check 'em out, since pynastran handles complete nastran decks (that contain also simulation instructions). If not present, I can provide a basic one.
Is a test similar to the pyvista one fine?

finsberg · 2026-05-12T15:27:49Z

I think this is a good start. I guess the optimal thing would be to have the nastran grids stored somewhere else (like Zenodo) and fetch them if they are not present on the system. @finsberg what do you think?
Nice work @bayswiss. I think this looks very good. Having a test in place where we can test on some real meshes would be good. Perhaps we can just grab some of the meshes from this repo: https://github.com/SteveDoyle2/pyNastran/tree/main/models ?
Thank you @finsberg. I will check 'em out, since pynastran handles complete nastran decks (that contain also simulation instructions). If not present, I can provide a basic one. Is a test similar to the pyvista one fine?

A simliar test as the pyvista one if fine. The most important thing is to have a test in place that tests the basic functionality. I don't know if there are a lot of variations in nastran files, but might be good to have some tests that covers the common scenarios. For example if mixed cell types are common it is good to have test for that.

It is also possible to add a step in in the test_workflow.yml which can download the data used by the tests. Whether this is from another repository (like pynastran) or Zenodo doesn't really matter.

bayswiss · 2026-05-12T15:52:53Z

A simliar test as the pyvista one if fine. The most important thing is to have a test in place that tests the basic functionality. I don't know if there are a lot of variations in nastran files, but might be good to have some tests that covers the common scenarios. For example if mixed cell types are common it is good to have test for that.
It is also possible to add a step in in the test_workflow.yml which can download the data used by the tests. Whether this is from another repository (like pynastran) or Zenodo doesn't really matter.

I will start working on the basic test. Regarding mixed meshes, what am I missing? is dolfinx going to support them soon (I am on 0.10.0 currently)?

jorgensd · 2026-05-14T20:12:59Z

A simliar test as the pyvista one if fine. The most important thing is to have a test in place that tests the basic functionality. I don't know if there are a lot of variations in nastran files, but might be good to have some tests that covers the common scenarios. For example if mixed cell types are common it is good to have test for that.
It is also possible to add a step in in the test_workflow.yml which can download the data used by the tests. Whether this is from another repository (like pynastran) or Zenodo doesn't really matter.
I will start working on the basic test. Regarding mixed meshes, what am I missing? is dolfinx going to support them soon (I am on 0.10.0 currently)?

There is already partial support for mixed meshes. The PR I opened today makes it possible to read those meshes from gmsh: FEniCS/dolfinx#4214

bayswiss · 2026-05-15T13:34:38Z

@jorgensd Sorry for the slow reply. Here's an example of what is sometimes called a "hexcore" mesh:
hexacore.zip

The idea is to fill the bulk of the domain with a Cartesian hex grid and use tets only near the boundary to handle geometric complexity, with pyramids as transition elements. The appeal is getting most of the numerical benefits of a structured hex mesh without actually having to build one.

One concern for wave propagation applications: the hex-pyramid-tet interface introduces a local change in dispersion characteristics, which can act as a weak spurious reflector. Not a dealbreaker, but worth keeping in mind depending on the frequency range (I actually don't use it but I've seen it a lot).

P.S. The parallelepiped is just to show the element structure, obviously nobody would use a mixed mesh approach on a geometry this simple.

jorgensd · 2026-05-15T14:07:56Z

@jorgensd Sorry for the slow reply. Here's an example of what is sometimes called a "hexcore" mesh:
hexacore.zip
The idea is to fill the bulk of the domain with a Cartesian hex grid and use tets only near the boundary to handle geometric complexity, with pyramids as transition elements. The appeal is getting most of the numerical benefits of a structured hex mesh without actually having to build one.
One concern for wave propagation applications: the hex-pyramid-tet interface introduces a local change dispersion characteristics, which can act as a weak spurious reflector. Not a dealbreaker, but worth keeping in mind depending on the frequency range (I actually don't use it but I've seen it a lot).
P.S. The parallelepiped is just to show the element structure, obviously nobody would use a mixed mesh approach on a geometry this simple.

No worries, as you see, there were some missing pieces in the gmshio code to read such meshes, which should hopefully be resolved with my PR.

bayswiss · 2026-05-06T16:04:49Z

Status: Draft - opening for early feedback before adding tests.

Refers #43

Tested manually outside the repo against multiple nastran meshes generated with different commercial preprocessors.

Before polishing I'd like input on where Nastran test inputs should live and what level of testing is needed. Do I commit a small bdf and run a test similar to "test_pyvista.py"?

for more information, see https://pre-commit.ci

jorgensd · 2026-05-12T11:11:28Z

+ if not topologies:
+ raise ValueError(f"No elements found in {filename}.")
+
+ elements = []


Maybe a comment here that explains that the main purpose of everything up to Line 329 is to sanity check that we have extracted some elements of a given cell type with a given name.

I will add that

jorgensd · 2026-05-12T11:12:11Z

+ elements = []
+ for gmsh_type in topologies:
+ _, dim, _, n_nodes, *_ = gmsh.model.mesh.getElementProperties(gmsh_type)
+ elements.append((dim, n_nodes, gmsh_type))
+
+ dims = [e[0] for e in elements]
+ if len(dims) != len(set(dims)):
+ raise ValueError(
+ f"Multiple element types share a topological dimension in {filename}."
+ )
+ _, num_nodes, gmsh_type = max(elements, key=lambda e: e[0])


I guess this is also mainly for error handling/sanity checking perspective?

Yes. Nastran mixed meshes (hexa-pyramid-tetra) are very common in some commercial preprocessors

We could add support for these kinds of meshes, as they are supported in DOLFINx, albeit the interface is very rough. If you have a link to a mixed type mesh I can have a go at improving your API.

jorgensd · 2026-05-12T11:13:02Z

I think this is a good start. I guess the optimal thing would be to have the nastran grids stored somewhere else (like Zenodo) and fetch them if they are not present on the system. @finsberg what do you think?

finsberg · 2026-05-12T14:38:51Z

I think this is a good start. I guess the optimal thing would be to have the nastran grids stored somewhere else (like Zenodo) and fetch them if they are not present on the system. @finsberg what do you think?

Nice work @bayswiss. I think this looks very good. Having a test in place where we can test on some real meshes would be good. Perhaps we can just grab some of the meshes from this repo: https://github.com/SteveDoyle2/pyNastran/tree/main/models ?

bayswiss · 2026-05-12T14:46:12Z

I think this is a good start. I guess the optimal thing would be to have the nastran grids stored somewhere else (like Zenodo) and fetch them if they are not present on the system. @finsberg what do you think?
Nice work @bayswiss. I think this looks very good. Having a test in place where we can test on some real meshes would be good. Perhaps we can just grab some of the meshes from this repo: https://github.com/SteveDoyle2/pyNastran/tree/main/models ?

Thank you @finsberg. I will check 'em out, since pynastran handles complete nastran decks (that contain also simulation instructions). If not present, I can provide a basic one.
Is a test similar to the pyvista one fine?

finsberg · 2026-05-12T15:27:49Z

I think this is a good start. I guess the optimal thing would be to have the nastran grids stored somewhere else (like Zenodo) and fetch them if they are not present on the system. @finsberg what do you think?
Nice work @bayswiss. I think this looks very good. Having a test in place where we can test on some real meshes would be good. Perhaps we can just grab some of the meshes from this repo: https://github.com/SteveDoyle2/pyNastran/tree/main/models ?
Thank you @finsberg. I will check 'em out, since pynastran handles complete nastran decks (that contain also simulation instructions). If not present, I can provide a basic one. Is a test similar to the pyvista one fine?

A simliar test as the pyvista one if fine. The most important thing is to have a test in place that tests the basic functionality. I don't know if there are a lot of variations in nastran files, but might be good to have some tests that covers the common scenarios. For example if mixed cell types are common it is good to have test for that.

It is also possible to add a step in in the test_workflow.yml which can download the data used by the tests. Whether this is from another repository (like pynastran) or Zenodo doesn't really matter.

bayswiss · 2026-05-12T15:52:53Z

A simliar test as the pyvista one if fine. The most important thing is to have a test in place that tests the basic functionality. I don't know if there are a lot of variations in nastran files, but might be good to have some tests that covers the common scenarios. For example if mixed cell types are common it is good to have test for that.
It is also possible to add a step in in the test_workflow.yml which can download the data used by the tests. Whether this is from another repository (like pynastran) or Zenodo doesn't really matter.

I will start working on the basic test. Regarding mixed meshes, what am I missing? is dolfinx going to support them soon (I am on 0.10.0 currently)?

jorgensd · 2026-05-14T20:12:59Z

A simliar test as the pyvista one if fine. The most important thing is to have a test in place that tests the basic functionality. I don't know if there are a lot of variations in nastran files, but might be good to have some tests that covers the common scenarios. For example if mixed cell types are common it is good to have test for that.
It is also possible to add a step in in the test_workflow.yml which can download the data used by the tests. Whether this is from another repository (like pynastran) or Zenodo doesn't really matter.
I will start working on the basic test. Regarding mixed meshes, what am I missing? is dolfinx going to support them soon (I am on 0.10.0 currently)?

There is already partial support for mixed meshes. The PR I opened today makes it possible to read those meshes from gmsh: FEniCS/dolfinx#4214

bayswiss · 2026-05-15T13:34:38Z

@jorgensd Sorry for the slow reply. Here's an example of what is sometimes called a "hexcore" mesh:
hexacore.zip

The idea is to fill the bulk of the domain with a Cartesian hex grid and use tets only near the boundary to handle geometric complexity, with pyramids as transition elements. The appeal is getting most of the numerical benefits of a structured hex mesh without actually having to build one.

One concern for wave propagation applications: the hex-pyramid-tet interface introduces a local change in dispersion characteristics, which can act as a weak spurious reflector. Not a dealbreaker, but worth keeping in mind depending on the frequency range (I actually don't use it but I've seen it a lot).

P.S. The parallelepiped is just to show the element structure, obviously nobody would use a mixed mesh approach on a geometry this simple.

jorgensd · 2026-05-15T14:07:56Z

@jorgensd Sorry for the slow reply. Here's an example of what is sometimes called a "hexcore" mesh:
hexacore.zip
The idea is to fill the bulk of the domain with a Cartesian hex grid and use tets only near the boundary to handle geometric complexity, with pyramids as transition elements. The appeal is getting most of the numerical benefits of a structured hex mesh without actually having to build one.
One concern for wave propagation applications: the hex-pyramid-tet interface introduces a local change dispersion characteristics, which can act as a weak spurious reflector. Not a dealbreaker, but worth keeping in mind depending on the frequency range (I actually don't use it but I've seen it a lot).
P.S. The parallelepiped is just to show the element structure, obviously nobody would use a mixed mesh approach on a geometry this simple.

No worries, as you see, there were some missing pieces in the gmshio code to read such meshes, which should hopefully be resolved with my PR.

bayswiss · 2026-05-06T16:04:49Z

Status: Draft - opening for early feedback before adding tests.

Refers #43

Tested manually outside the repo against multiple nastran meshes generated with different commercial preprocessors.

Before polishing I'd like input on where Nastran test inputs should live and what level of testing is needed. Do I commit a small bdf and run a test similar to "test_pyvista.py"?

for more information, see https://pre-commit.ci

jorgensd · 2026-05-12T11:11:28Z

+ if not topologies:
+ raise ValueError(f"No elements found in {filename}.")
+
+ elements = []


Maybe a comment here that explains that the main purpose of everything up to Line 329 is to sanity check that we have extracted some elements of a given cell type with a given name.

I will add that

jorgensd · 2026-05-12T11:12:11Z

+ elements = []
+ for gmsh_type in topologies:
+ _, dim, _, n_nodes, *_ = gmsh.model.mesh.getElementProperties(gmsh_type)
+ elements.append((dim, n_nodes, gmsh_type))
+
+ dims = [e[0] for e in elements]
+ if len(dims) != len(set(dims)):
+ raise ValueError(
+ f"Multiple element types share a topological dimension in {filename}."
+ )
+ _, num_nodes, gmsh_type = max(elements, key=lambda e: e[0])


I guess this is also mainly for error handling/sanity checking perspective?

Yes. Nastran mixed meshes (hexa-pyramid-tetra) are very common in some commercial preprocessors

We could add support for these kinds of meshes, as they are supported in DOLFINx, albeit the interface is very rough. If you have a link to a mixed type mesh I can have a go at improving your API.

jorgensd · 2026-05-12T11:13:02Z

I think this is a good start. I guess the optimal thing would be to have the nastran grids stored somewhere else (like Zenodo) and fetch them if they are not present on the system. @finsberg what do you think?

finsberg · 2026-05-12T14:38:51Z

I think this is a good start. I guess the optimal thing would be to have the nastran grids stored somewhere else (like Zenodo) and fetch them if they are not present on the system. @finsberg what do you think?

Nice work @bayswiss. I think this looks very good. Having a test in place where we can test on some real meshes would be good. Perhaps we can just grab some of the meshes from this repo: https://github.com/SteveDoyle2/pyNastran/tree/main/models ?

bayswiss · 2026-05-12T14:46:12Z

I think this is a good start. I guess the optimal thing would be to have the nastran grids stored somewhere else (like Zenodo) and fetch them if they are not present on the system. @finsberg what do you think?
Nice work @bayswiss. I think this looks very good. Having a test in place where we can test on some real meshes would be good. Perhaps we can just grab some of the meshes from this repo: https://github.com/SteveDoyle2/pyNastran/tree/main/models ?

Thank you @finsberg. I will check 'em out, since pynastran handles complete nastran decks (that contain also simulation instructions). If not present, I can provide a basic one.
Is a test similar to the pyvista one fine?

finsberg · 2026-05-12T15:27:49Z

I think this is a good start. I guess the optimal thing would be to have the nastran grids stored somewhere else (like Zenodo) and fetch them if they are not present on the system. @finsberg what do you think?
Nice work @bayswiss. I think this looks very good. Having a test in place where we can test on some real meshes would be good. Perhaps we can just grab some of the meshes from this repo: https://github.com/SteveDoyle2/pyNastran/tree/main/models ?
Thank you @finsberg. I will check 'em out, since pynastran handles complete nastran decks (that contain also simulation instructions). If not present, I can provide a basic one. Is a test similar to the pyvista one fine?

A simliar test as the pyvista one if fine. The most important thing is to have a test in place that tests the basic functionality. I don't know if there are a lot of variations in nastran files, but might be good to have some tests that covers the common scenarios. For example if mixed cell types are common it is good to have test for that.

It is also possible to add a step in in the test_workflow.yml which can download the data used by the tests. Whether this is from another repository (like pynastran) or Zenodo doesn't really matter.

bayswiss · 2026-05-12T15:52:53Z

A simliar test as the pyvista one if fine. The most important thing is to have a test in place that tests the basic functionality. I don't know if there are a lot of variations in nastran files, but might be good to have some tests that covers the common scenarios. For example if mixed cell types are common it is good to have test for that.
It is also possible to add a step in in the test_workflow.yml which can download the data used by the tests. Whether this is from another repository (like pynastran) or Zenodo doesn't really matter.

I will start working on the basic test. Regarding mixed meshes, what am I missing? is dolfinx going to support them soon (I am on 0.10.0 currently)?

jorgensd · 2026-05-14T20:12:59Z

A simliar test as the pyvista one if fine. The most important thing is to have a test in place that tests the basic functionality. I don't know if there are a lot of variations in nastran files, but might be good to have some tests that covers the common scenarios. For example if mixed cell types are common it is good to have test for that.
It is also possible to add a step in in the test_workflow.yml which can download the data used by the tests. Whether this is from another repository (like pynastran) or Zenodo doesn't really matter.
I will start working on the basic test. Regarding mixed meshes, what am I missing? is dolfinx going to support them soon (I am on 0.10.0 currently)?

There is already partial support for mixed meshes. The PR I opened today makes it possible to read those meshes from gmsh: FEniCS/dolfinx#4214

bayswiss · 2026-05-15T13:34:38Z

@jorgensd Sorry for the slow reply. Here's an example of what is sometimes called a "hexcore" mesh:
hexacore.zip

The idea is to fill the bulk of the domain with a Cartesian hex grid and use tets only near the boundary to handle geometric complexity, with pyramids as transition elements. The appeal is getting most of the numerical benefits of a structured hex mesh without actually having to build one.

One concern for wave propagation applications: the hex-pyramid-tet interface introduces a local change in dispersion characteristics, which can act as a weak spurious reflector. Not a dealbreaker, but worth keeping in mind depending on the frequency range (I actually don't use it but I've seen it a lot).

P.S. The parallelepiped is just to show the element structure, obviously nobody would use a mixed mesh approach on a geometry this simple.

jorgensd · 2026-05-15T14:07:56Z

@jorgensd Sorry for the slow reply. Here's an example of what is sometimes called a "hexcore" mesh:
hexacore.zip
The idea is to fill the bulk of the domain with a Cartesian hex grid and use tets only near the boundary to handle geometric complexity, with pyramids as transition elements. The appeal is getting most of the numerical benefits of a structured hex mesh without actually having to build one.
One concern for wave propagation applications: the hex-pyramid-tet interface introduces a local change dispersion characteristics, which can act as a weak spurious reflector. Not a dealbreaker, but worth keeping in mind depending on the frequency range (I actually don't use it but I've seen it a lot).
P.S. The parallelepiped is just to show the element structure, obviously nobody would use a mixed mesh approach on a geometry this simple.

No worries, as you see, there were some missing pieces in the gmshio code to read such meshes, which should hopefully be resolved with my PR.

bayswiss · 2026-05-06T16:04:49Z

Status: Draft - opening for early feedback before adding tests.

Refers #43

Tested manually outside the repo against multiple nastran meshes generated with different commercial preprocessors.

Before polishing I'd like input on where Nastran test inputs should live and what level of testing is needed. Do I commit a small bdf and run a test similar to "test_pyvista.py"?

for more information, see https://pre-commit.ci

jorgensd · 2026-05-12T11:11:28Z

+ if not topologies:
+ raise ValueError(f"No elements found in {filename}.")
+
+ elements = []


Maybe a comment here that explains that the main purpose of everything up to Line 329 is to sanity check that we have extracted some elements of a given cell type with a given name.

I will add that

jorgensd · 2026-05-12T11:12:11Z

+ elements = []
+ for gmsh_type in topologies:
+ _, dim, _, n_nodes, *_ = gmsh.model.mesh.getElementProperties(gmsh_type)
+ elements.append((dim, n_nodes, gmsh_type))
+
+ dims = [e[0] for e in elements]
+ if len(dims) != len(set(dims)):
+ raise ValueError(
+ f"Multiple element types share a topological dimension in {filename}."
+ )
+ _, num_nodes, gmsh_type = max(elements, key=lambda e: e[0])


I guess this is also mainly for error handling/sanity checking perspective?

Yes. Nastran mixed meshes (hexa-pyramid-tetra) are very common in some commercial preprocessors

We could add support for these kinds of meshes, as they are supported in DOLFINx, albeit the interface is very rough. If you have a link to a mixed type mesh I can have a go at improving your API.

jorgensd · 2026-05-12T11:13:02Z

I think this is a good start. I guess the optimal thing would be to have the nastran grids stored somewhere else (like Zenodo) and fetch them if they are not present on the system. @finsberg what do you think?

finsberg · 2026-05-12T14:38:51Z

I think this is a good start. I guess the optimal thing would be to have the nastran grids stored somewhere else (like Zenodo) and fetch them if they are not present on the system. @finsberg what do you think?

Nice work @bayswiss. I think this looks very good. Having a test in place where we can test on some real meshes would be good. Perhaps we can just grab some of the meshes from this repo: https://github.com/SteveDoyle2/pyNastran/tree/main/models ?

bayswiss · 2026-05-12T14:46:12Z

I think this is a good start. I guess the optimal thing would be to have the nastran grids stored somewhere else (like Zenodo) and fetch them if they are not present on the system. @finsberg what do you think?
Nice work @bayswiss. I think this looks very good. Having a test in place where we can test on some real meshes would be good. Perhaps we can just grab some of the meshes from this repo: https://github.com/SteveDoyle2/pyNastran/tree/main/models ?

Thank you @finsberg. I will check 'em out, since pynastran handles complete nastran decks (that contain also simulation instructions). If not present, I can provide a basic one.
Is a test similar to the pyvista one fine?

finsberg · 2026-05-12T15:27:49Z

I think this is a good start. I guess the optimal thing would be to have the nastran grids stored somewhere else (like Zenodo) and fetch them if they are not present on the system. @finsberg what do you think?
Nice work @bayswiss. I think this looks very good. Having a test in place where we can test on some real meshes would be good. Perhaps we can just grab some of the meshes from this repo: https://github.com/SteveDoyle2/pyNastran/tree/main/models ?
Thank you @finsberg. I will check 'em out, since pynastran handles complete nastran decks (that contain also simulation instructions). If not present, I can provide a basic one. Is a test similar to the pyvista one fine?

A simliar test as the pyvista one if fine. The most important thing is to have a test in place that tests the basic functionality. I don't know if there are a lot of variations in nastran files, but might be good to have some tests that covers the common scenarios. For example if mixed cell types are common it is good to have test for that.

It is also possible to add a step in in the test_workflow.yml which can download the data used by the tests. Whether this is from another repository (like pynastran) or Zenodo doesn't really matter.

bayswiss · 2026-05-12T15:52:53Z

A simliar test as the pyvista one if fine. The most important thing is to have a test in place that tests the basic functionality. I don't know if there are a lot of variations in nastran files, but might be good to have some tests that covers the common scenarios. For example if mixed cell types are common it is good to have test for that.
It is also possible to add a step in in the test_workflow.yml which can download the data used by the tests. Whether this is from another repository (like pynastran) or Zenodo doesn't really matter.

I will start working on the basic test. Regarding mixed meshes, what am I missing? is dolfinx going to support them soon (I am on 0.10.0 currently)?

jorgensd · 2026-05-14T20:12:59Z

A simliar test as the pyvista one if fine. The most important thing is to have a test in place that tests the basic functionality. I don't know if there are a lot of variations in nastran files, but might be good to have some tests that covers the common scenarios. For example if mixed cell types are common it is good to have test for that.
It is also possible to add a step in in the test_workflow.yml which can download the data used by the tests. Whether this is from another repository (like pynastran) or Zenodo doesn't really matter.
I will start working on the basic test. Regarding mixed meshes, what am I missing? is dolfinx going to support them soon (I am on 0.10.0 currently)?

There is already partial support for mixed meshes. The PR I opened today makes it possible to read those meshes from gmsh: FEniCS/dolfinx#4214

bayswiss · 2026-05-15T13:34:38Z

@jorgensd Sorry for the slow reply. Here's an example of what is sometimes called a "hexcore" mesh:
hexacore.zip

The idea is to fill the bulk of the domain with a Cartesian hex grid and use tets only near the boundary to handle geometric complexity, with pyramids as transition elements. The appeal is getting most of the numerical benefits of a structured hex mesh without actually having to build one.

One concern for wave propagation applications: the hex-pyramid-tet interface introduces a local change in dispersion characteristics, which can act as a weak spurious reflector. Not a dealbreaker, but worth keeping in mind depending on the frequency range (I actually don't use it but I've seen it a lot).

P.S. The parallelepiped is just to show the element structure, obviously nobody would use a mixed mesh approach on a geometry this simple.

jorgensd · 2026-05-15T14:07:56Z

@jorgensd Sorry for the slow reply. Here's an example of what is sometimes called a "hexcore" mesh:
hexacore.zip
The idea is to fill the bulk of the domain with a Cartesian hex grid and use tets only near the boundary to handle geometric complexity, with pyramids as transition elements. The appeal is getting most of the numerical benefits of a structured hex mesh without actually having to build one.
One concern for wave propagation applications: the hex-pyramid-tet interface introduces a local change dispersion characteristics, which can act as a weak spurious reflector. Not a dealbreaker, but worth keeping in mind depending on the frequency range (I actually don't use it but I've seen it a lot).
P.S. The parallelepiped is just to show the element structure, obviously nobody would use a mixed mesh approach on a geometry this simple.

No worries, as you see, there were some missing pieces in the gmshio code to read such meshes, which should hopefully be resolved with my PR.

bayswiss · 2026-05-06T16:04:49Z

Status: Draft - opening for early feedback before adding tests.

Refers #43

Tested manually outside the repo against multiple nastran meshes generated with different commercial preprocessors.

Before polishing I'd like input on where Nastran test inputs should live and what level of testing is needed. Do I commit a small bdf and run a test similar to "test_pyvista.py"?

for more information, see https://pre-commit.ci

jorgensd · 2026-05-12T11:11:28Z

+ if not topologies:
+ raise ValueError(f"No elements found in {filename}.")
+
+ elements = []


Maybe a comment here that explains that the main purpose of everything up to Line 329 is to sanity check that we have extracted some elements of a given cell type with a given name.

I will add that

jorgensd · 2026-05-12T11:12:11Z

+ elements = []
+ for gmsh_type in topologies:
+ _, dim, _, n_nodes, *_ = gmsh.model.mesh.getElementProperties(gmsh_type)
+ elements.append((dim, n_nodes, gmsh_type))
+
+ dims = [e[0] for e in elements]
+ if len(dims) != len(set(dims)):
+ raise ValueError(
+ f"Multiple element types share a topological dimension in {filename}."
+ )
+ _, num_nodes, gmsh_type = max(elements, key=lambda e: e[0])


I guess this is also mainly for error handling/sanity checking perspective?

Yes. Nastran mixed meshes (hexa-pyramid-tetra) are very common in some commercial preprocessors

We could add support for these kinds of meshes, as they are supported in DOLFINx, albeit the interface is very rough. If you have a link to a mixed type mesh I can have a go at improving your API.

jorgensd · 2026-05-12T11:13:02Z

I think this is a good start. I guess the optimal thing would be to have the nastran grids stored somewhere else (like Zenodo) and fetch them if they are not present on the system. @finsberg what do you think?

finsberg · 2026-05-12T14:38:51Z

I think this is a good start. I guess the optimal thing would be to have the nastran grids stored somewhere else (like Zenodo) and fetch them if they are not present on the system. @finsberg what do you think?

Nice work @bayswiss. I think this looks very good. Having a test in place where we can test on some real meshes would be good. Perhaps we can just grab some of the meshes from this repo: https://github.com/SteveDoyle2/pyNastran/tree/main/models ?

bayswiss · 2026-05-12T14:46:12Z

I think this is a good start. I guess the optimal thing would be to have the nastran grids stored somewhere else (like Zenodo) and fetch them if they are not present on the system. @finsberg what do you think?
Nice work @bayswiss. I think this looks very good. Having a test in place where we can test on some real meshes would be good. Perhaps we can just grab some of the meshes from this repo: https://github.com/SteveDoyle2/pyNastran/tree/main/models ?

Thank you @finsberg. I will check 'em out, since pynastran handles complete nastran decks (that contain also simulation instructions). If not present, I can provide a basic one.
Is a test similar to the pyvista one fine?

finsberg · 2026-05-12T15:27:49Z

I think this is a good start. I guess the optimal thing would be to have the nastran grids stored somewhere else (like Zenodo) and fetch them if they are not present on the system. @finsberg what do you think?
Nice work @bayswiss. I think this looks very good. Having a test in place where we can test on some real meshes would be good. Perhaps we can just grab some of the meshes from this repo: https://github.com/SteveDoyle2/pyNastran/tree/main/models ?
Thank you @finsberg. I will check 'em out, since pynastran handles complete nastran decks (that contain also simulation instructions). If not present, I can provide a basic one. Is a test similar to the pyvista one fine?

A simliar test as the pyvista one if fine. The most important thing is to have a test in place that tests the basic functionality. I don't know if there are a lot of variations in nastran files, but might be good to have some tests that covers the common scenarios. For example if mixed cell types are common it is good to have test for that.

It is also possible to add a step in in the test_workflow.yml which can download the data used by the tests. Whether this is from another repository (like pynastran) or Zenodo doesn't really matter.

bayswiss · 2026-05-12T15:52:53Z

A simliar test as the pyvista one if fine. The most important thing is to have a test in place that tests the basic functionality. I don't know if there are a lot of variations in nastran files, but might be good to have some tests that covers the common scenarios. For example if mixed cell types are common it is good to have test for that.
It is also possible to add a step in in the test_workflow.yml which can download the data used by the tests. Whether this is from another repository (like pynastran) or Zenodo doesn't really matter.

I will start working on the basic test. Regarding mixed meshes, what am I missing? is dolfinx going to support them soon (I am on 0.10.0 currently)?

jorgensd · 2026-05-14T20:12:59Z

A simliar test as the pyvista one if fine. The most important thing is to have a test in place that tests the basic functionality. I don't know if there are a lot of variations in nastran files, but might be good to have some tests that covers the common scenarios. For example if mixed cell types are common it is good to have test for that.
It is also possible to add a step in in the test_workflow.yml which can download the data used by the tests. Whether this is from another repository (like pynastran) or Zenodo doesn't really matter.
I will start working on the basic test. Regarding mixed meshes, what am I missing? is dolfinx going to support them soon (I am on 0.10.0 currently)?

There is already partial support for mixed meshes. The PR I opened today makes it possible to read those meshes from gmsh: FEniCS/dolfinx#4214

bayswiss · 2026-05-15T13:34:38Z

@jorgensd Sorry for the slow reply. Here's an example of what is sometimes called a "hexcore" mesh:
hexacore.zip

The idea is to fill the bulk of the domain with a Cartesian hex grid and use tets only near the boundary to handle geometric complexity, with pyramids as transition elements. The appeal is getting most of the numerical benefits of a structured hex mesh without actually having to build one.

One concern for wave propagation applications: the hex-pyramid-tet interface introduces a local change in dispersion characteristics, which can act as a weak spurious reflector. Not a dealbreaker, but worth keeping in mind depending on the frequency range (I actually don't use it but I've seen it a lot).

P.S. The parallelepiped is just to show the element structure, obviously nobody would use a mixed mesh approach on a geometry this simple.

jorgensd · 2026-05-15T14:07:56Z

@jorgensd Sorry for the slow reply. Here's an example of what is sometimes called a "hexcore" mesh:
hexacore.zip
The idea is to fill the bulk of the domain with a Cartesian hex grid and use tets only near the boundary to handle geometric complexity, with pyramids as transition elements. The appeal is getting most of the numerical benefits of a structured hex mesh without actually having to build one.
One concern for wave propagation applications: the hex-pyramid-tet interface introduces a local change dispersion characteristics, which can act as a weak spurious reflector. Not a dealbreaker, but worth keeping in mind depending on the frequency range (I actually don't use it but I've seen it a lot).
P.S. The parallelepiped is just to show the element structure, obviously nobody would use a mixed mesh approach on a geometry this simple.

No worries, as you see, there were some missing pieces in the gmshio code to read such meshes, which should hopefully be resolved with my PR.

bayswiss · 2026-05-06T16:04:49Z

Status: Draft - opening for early feedback before adding tests.

Refers #43

Tested manually outside the repo against multiple nastran meshes generated with different commercial preprocessors.

Before polishing I'd like input on where Nastran test inputs should live and what level of testing is needed. Do I commit a small bdf and run a test similar to "test_pyvista.py"?

for more information, see https://pre-commit.ci

jorgensd · 2026-05-12T11:11:28Z

+ if not topologies:
+ raise ValueError(f"No elements found in {filename}.")
+
+ elements = []


Maybe a comment here that explains that the main purpose of everything up to Line 329 is to sanity check that we have extracted some elements of a given cell type with a given name.

I will add that

jorgensd · 2026-05-12T11:12:11Z

+ elements = []
+ for gmsh_type in topologies:
+ _, dim, _, n_nodes, *_ = gmsh.model.mesh.getElementProperties(gmsh_type)
+ elements.append((dim, n_nodes, gmsh_type))
+
+ dims = [e[0] for e in elements]
+ if len(dims) != len(set(dims)):
+ raise ValueError(
+ f"Multiple element types share a topological dimension in {filename}."
+ )
+ _, num_nodes, gmsh_type = max(elements, key=lambda e: e[0])


I guess this is also mainly for error handling/sanity checking perspective?

Yes. Nastran mixed meshes (hexa-pyramid-tetra) are very common in some commercial preprocessors

We could add support for these kinds of meshes, as they are supported in DOLFINx, albeit the interface is very rough. If you have a link to a mixed type mesh I can have a go at improving your API.

jorgensd · 2026-05-12T11:13:02Z

I think this is a good start. I guess the optimal thing would be to have the nastran grids stored somewhere else (like Zenodo) and fetch them if they are not present on the system. @finsberg what do you think?

finsberg · 2026-05-12T14:38:51Z

I think this is a good start. I guess the optimal thing would be to have the nastran grids stored somewhere else (like Zenodo) and fetch them if they are not present on the system. @finsberg what do you think?

Nice work @bayswiss. I think this looks very good. Having a test in place where we can test on some real meshes would be good. Perhaps we can just grab some of the meshes from this repo: https://github.com/SteveDoyle2/pyNastran/tree/main/models ?

bayswiss · 2026-05-12T14:46:12Z

I think this is a good start. I guess the optimal thing would be to have the nastran grids stored somewhere else (like Zenodo) and fetch them if they are not present on the system. @finsberg what do you think?
Nice work @bayswiss. I think this looks very good. Having a test in place where we can test on some real meshes would be good. Perhaps we can just grab some of the meshes from this repo: https://github.com/SteveDoyle2/pyNastran/tree/main/models ?

Thank you @finsberg. I will check 'em out, since pynastran handles complete nastran decks (that contain also simulation instructions). If not present, I can provide a basic one.
Is a test similar to the pyvista one fine?

finsberg · 2026-05-12T15:27:49Z

I think this is a good start. I guess the optimal thing would be to have the nastran grids stored somewhere else (like Zenodo) and fetch them if they are not present on the system. @finsberg what do you think?
Nice work @bayswiss. I think this looks very good. Having a test in place where we can test on some real meshes would be good. Perhaps we can just grab some of the meshes from this repo: https://github.com/SteveDoyle2/pyNastran/tree/main/models ?
Thank you @finsberg. I will check 'em out, since pynastran handles complete nastran decks (that contain also simulation instructions). If not present, I can provide a basic one. Is a test similar to the pyvista one fine?

A simliar test as the pyvista one if fine. The most important thing is to have a test in place that tests the basic functionality. I don't know if there are a lot of variations in nastran files, but might be good to have some tests that covers the common scenarios. For example if mixed cell types are common it is good to have test for that.

It is also possible to add a step in in the test_workflow.yml which can download the data used by the tests. Whether this is from another repository (like pynastran) or Zenodo doesn't really matter.

bayswiss · 2026-05-12T15:52:53Z

A simliar test as the pyvista one if fine. The most important thing is to have a test in place that tests the basic functionality. I don't know if there are a lot of variations in nastran files, but might be good to have some tests that covers the common scenarios. For example if mixed cell types are common it is good to have test for that.
It is also possible to add a step in in the test_workflow.yml which can download the data used by the tests. Whether this is from another repository (like pynastran) or Zenodo doesn't really matter.

I will start working on the basic test. Regarding mixed meshes, what am I missing? is dolfinx going to support them soon (I am on 0.10.0 currently)?

jorgensd · 2026-05-14T20:12:59Z

A simliar test as the pyvista one if fine. The most important thing is to have a test in place that tests the basic functionality. I don't know if there are a lot of variations in nastran files, but might be good to have some tests that covers the common scenarios. For example if mixed cell types are common it is good to have test for that.
It is also possible to add a step in in the test_workflow.yml which can download the data used by the tests. Whether this is from another repository (like pynastran) or Zenodo doesn't really matter.
I will start working on the basic test. Regarding mixed meshes, what am I missing? is dolfinx going to support them soon (I am on 0.10.0 currently)?

There is already partial support for mixed meshes. The PR I opened today makes it possible to read those meshes from gmsh: FEniCS/dolfinx#4214

bayswiss · 2026-05-15T13:34:38Z

@jorgensd Sorry for the slow reply. Here's an example of what is sometimes called a "hexcore" mesh:
hexacore.zip

The idea is to fill the bulk of the domain with a Cartesian hex grid and use tets only near the boundary to handle geometric complexity, with pyramids as transition elements. The appeal is getting most of the numerical benefits of a structured hex mesh without actually having to build one.

One concern for wave propagation applications: the hex-pyramid-tet interface introduces a local change in dispersion characteristics, which can act as a weak spurious reflector. Not a dealbreaker, but worth keeping in mind depending on the frequency range (I actually don't use it but I've seen it a lot).

P.S. The parallelepiped is just to show the element structure, obviously nobody would use a mixed mesh approach on a geometry this simple.

jorgensd · 2026-05-15T14:07:56Z

@jorgensd Sorry for the slow reply. Here's an example of what is sometimes called a "hexcore" mesh:
hexacore.zip
The idea is to fill the bulk of the domain with a Cartesian hex grid and use tets only near the boundary to handle geometric complexity, with pyramids as transition elements. The appeal is getting most of the numerical benefits of a structured hex mesh without actually having to build one.
One concern for wave propagation applications: the hex-pyramid-tet interface introduces a local change dispersion characteristics, which can act as a weak spurious reflector. Not a dealbreaker, but worth keeping in mind depending on the frequency range (I actually don't use it but I've seen it a lot).
P.S. The parallelepiped is just to show the element structure, obviously nobody would use a mixed mesh approach on a geometry this simple.

No worries, as you see, there were some missing pieces in the gmshio code to read such meshes, which should hopefully be resolved with my PR.

bayswiss · 2026-05-06T16:04:49Z

Status: Draft - opening for early feedback before adding tests.

Refers #43

Tested manually outside the repo against multiple nastran meshes generated with different commercial preprocessors.

Before polishing I'd like input on where Nastran test inputs should live and what level of testing is needed. Do I commit a small bdf and run a test similar to "test_pyvista.py"?

for more information, see https://pre-commit.ci

jorgensd · 2026-05-12T11:11:28Z

+ if not topologies:
+ raise ValueError(f"No elements found in {filename}.")
+
+ elements = []


Maybe a comment here that explains that the main purpose of everything up to Line 329 is to sanity check that we have extracted some elements of a given cell type with a given name.

I will add that

jorgensd · 2026-05-12T11:12:11Z

+ elements = []
+ for gmsh_type in topologies:
+ _, dim, _, n_nodes, *_ = gmsh.model.mesh.getElementProperties(gmsh_type)
+ elements.append((dim, n_nodes, gmsh_type))
+
+ dims = [e[0] for e in elements]
+ if len(dims) != len(set(dims)):
+ raise ValueError(
+ f"Multiple element types share a topological dimension in {filename}."
+ )
+ _, num_nodes, gmsh_type = max(elements, key=lambda e: e[0])


I guess this is also mainly for error handling/sanity checking perspective?

Yes. Nastran mixed meshes (hexa-pyramid-tetra) are very common in some commercial preprocessors

We could add support for these kinds of meshes, as they are supported in DOLFINx, albeit the interface is very rough. If you have a link to a mixed type mesh I can have a go at improving your API.

jorgensd · 2026-05-12T11:13:02Z

I think this is a good start. I guess the optimal thing would be to have the nastran grids stored somewhere else (like Zenodo) and fetch them if they are not present on the system. @finsberg what do you think?

finsberg · 2026-05-12T14:38:51Z

I think this is a good start. I guess the optimal thing would be to have the nastran grids stored somewhere else (like Zenodo) and fetch them if they are not present on the system. @finsberg what do you think?

Nice work @bayswiss. I think this looks very good. Having a test in place where we can test on some real meshes would be good. Perhaps we can just grab some of the meshes from this repo: https://github.com/SteveDoyle2/pyNastran/tree/main/models ?

bayswiss · 2026-05-12T14:46:12Z

I think this is a good start. I guess the optimal thing would be to have the nastran grids stored somewhere else (like Zenodo) and fetch them if they are not present on the system. @finsberg what do you think?
Nice work @bayswiss. I think this looks very good. Having a test in place where we can test on some real meshes would be good. Perhaps we can just grab some of the meshes from this repo: https://github.com/SteveDoyle2/pyNastran/tree/main/models ?

Thank you @finsberg. I will check 'em out, since pynastran handles complete nastran decks (that contain also simulation instructions). If not present, I can provide a basic one.
Is a test similar to the pyvista one fine?

finsberg · 2026-05-12T15:27:49Z

I think this is a good start. I guess the optimal thing would be to have the nastran grids stored somewhere else (like Zenodo) and fetch them if they are not present on the system. @finsberg what do you think?
Nice work @bayswiss. I think this looks very good. Having a test in place where we can test on some real meshes would be good. Perhaps we can just grab some of the meshes from this repo: https://github.com/SteveDoyle2/pyNastran/tree/main/models ?
Thank you @finsberg. I will check 'em out, since pynastran handles complete nastran decks (that contain also simulation instructions). If not present, I can provide a basic one. Is a test similar to the pyvista one fine?

A simliar test as the pyvista one if fine. The most important thing is to have a test in place that tests the basic functionality. I don't know if there are a lot of variations in nastran files, but might be good to have some tests that covers the common scenarios. For example if mixed cell types are common it is good to have test for that.

It is also possible to add a step in in the test_workflow.yml which can download the data used by the tests. Whether this is from another repository (like pynastran) or Zenodo doesn't really matter.

bayswiss · 2026-05-12T15:52:53Z

A simliar test as the pyvista one if fine. The most important thing is to have a test in place that tests the basic functionality. I don't know if there are a lot of variations in nastran files, but might be good to have some tests that covers the common scenarios. For example if mixed cell types are common it is good to have test for that.
It is also possible to add a step in in the test_workflow.yml which can download the data used by the tests. Whether this is from another repository (like pynastran) or Zenodo doesn't really matter.

I will start working on the basic test. Regarding mixed meshes, what am I missing? is dolfinx going to support them soon (I am on 0.10.0 currently)?

jorgensd · 2026-05-14T20:12:59Z

A simliar test as the pyvista one if fine. The most important thing is to have a test in place that tests the basic functionality. I don't know if there are a lot of variations in nastran files, but might be good to have some tests that covers the common scenarios. For example if mixed cell types are common it is good to have test for that.
It is also possible to add a step in in the test_workflow.yml which can download the data used by the tests. Whether this is from another repository (like pynastran) or Zenodo doesn't really matter.
I will start working on the basic test. Regarding mixed meshes, what am I missing? is dolfinx going to support them soon (I am on 0.10.0 currently)?

There is already partial support for mixed meshes. The PR I opened today makes it possible to read those meshes from gmsh: FEniCS/dolfinx#4214

bayswiss · 2026-05-15T13:34:38Z

@jorgensd Sorry for the slow reply. Here's an example of what is sometimes called a "hexcore" mesh:
hexacore.zip

The idea is to fill the bulk of the domain with a Cartesian hex grid and use tets only near the boundary to handle geometric complexity, with pyramids as transition elements. The appeal is getting most of the numerical benefits of a structured hex mesh without actually having to build one.

One concern for wave propagation applications: the hex-pyramid-tet interface introduces a local change in dispersion characteristics, which can act as a weak spurious reflector. Not a dealbreaker, but worth keeping in mind depending on the frequency range (I actually don't use it but I've seen it a lot).

P.S. The parallelepiped is just to show the element structure, obviously nobody would use a mixed mesh approach on a geometry this simple.

jorgensd · 2026-05-15T14:07:56Z

@jorgensd Sorry for the slow reply. Here's an example of what is sometimes called a "hexcore" mesh:
hexacore.zip
The idea is to fill the bulk of the domain with a Cartesian hex grid and use tets only near the boundary to handle geometric complexity, with pyramids as transition elements. The appeal is getting most of the numerical benefits of a structured hex mesh without actually having to build one.
One concern for wave propagation applications: the hex-pyramid-tet interface introduces a local change dispersion characteristics, which can act as a weak spurious reflector. Not a dealbreaker, but worth keeping in mind depending on the frequency range (I actually don't use it but I've seen it a lot).
P.S. The parallelepiped is just to show the element structure, obviously nobody would use a mixed mesh approach on a geometry this simple.

No worries, as you see, there were some missing pieces in the gmshio code to read such meshes, which should hopefully be resolved with my PR.

bayswissand others added 4 commits May 6, 2026 16:30

read_mesh_data and read_meshtags data first implementation
179d9b2

hardcoding gdim 3
555a5ce

[pre-commit.ci] auto fixes from pre-commit.com hooks
547025c
for more information, see https://pre-commit.ci

minor fix and re-add docstring to read_mesh_data
c9bc950

jorgensd reviewed May 12, 2026
View reviewed changes

bayswissand others added 4 commits May 6, 2026 16:30

read_mesh_data and read_meshtags data first implementation
179d9b2

hardcoding gdim 3
555a5ce

[pre-commit.ci] auto fixes from pre-commit.com hooks
547025c
for more information, see https://pre-commit.ci

minor fix and re-add docstring to read_mesh_data
c9bc950

jorgensd reviewed May 12, 2026
View reviewed changes

bayswissand others added 4 commits May 6, 2026 16:30

read_mesh_data and read_meshtags data first implementation
179d9b2

hardcoding gdim 3
555a5ce

[pre-commit.ci] auto fixes from pre-commit.com hooks
547025c
for more information, see https://pre-commit.ci

minor fix and re-add docstring to read_mesh_data
c9bc950

jorgensd reviewed May 12, 2026
View reviewed changes

bayswissand others added 4 commits May 6, 2026 16:30

read_mesh_data and read_meshtags data first implementation
179d9b2

hardcoding gdim 3
555a5ce

[pre-commit.ci] auto fixes from pre-commit.com hooks
547025c
for more information, see https://pre-commit.ci

minor fix and re-add docstring to read_mesh_data
c9bc950

jorgensd reviewed May 12, 2026
View reviewed changes

bayswissand others added 4 commits May 6, 2026 16:30

read_mesh_data and read_meshtags data first implementation
179d9b2

hardcoding gdim 3
555a5ce

[pre-commit.ci] auto fixes from pre-commit.com hooks
547025c
for more information, see https://pre-commit.ci

minor fix and re-add docstring to read_mesh_data
c9bc950

jorgensd reviewed May 12, 2026
View reviewed changes

bayswissand others added 4 commits May 6, 2026 16:30

read_mesh_data and read_meshtags data first implementation
179d9b2

hardcoding gdim 3
555a5ce

[pre-commit.ci] auto fixes from pre-commit.com hooks
547025c
for more information, see https://pre-commit.ci

minor fix and re-add docstring to read_mesh_data
c9bc950

jorgensd reviewed May 12, 2026
View reviewed changes

bayswissand others added 4 commits May 6, 2026 16:30

read_mesh_data and read_meshtags data first implementation
179d9b2

hardcoding gdim 3
555a5ce

[pre-commit.ci] auto fixes from pre-commit.com hooks
547025c
for more information, see https://pre-commit.ci

minor fix and re-add docstring to read_mesh_data
c9bc950

jorgensd reviewed May 12, 2026
View reviewed changes

bayswissand others added 4 commits May 6, 2026 16:30

read_mesh_data and read_meshtags data first implementation
179d9b2

hardcoding gdim 3
555a5ce

[pre-commit.ci] auto fixes from pre-commit.com hooks
547025c
for more information, see https://pre-commit.ci

minor fix and re-add docstring to read_mesh_data
c9bc950

jorgensd reviewed May 12, 2026
View reviewed changes

Uh oh!

Conversation

bayswiss commented May 6, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bayswissMay 12, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jorgensd commented May 12, 2026

Uh oh!

finsberg commented May 12, 2026

Uh oh!

bayswiss commented May 12, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

finsberg commented May 12, 2026

Uh oh!

bayswiss commented May 12, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jorgensd commented May 14, 2026

Uh oh!

bayswiss commented May 15, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jorgensd commented May 15, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

bayswiss commented May 6, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bayswissMay 12, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jorgensd commented May 12, 2026

Uh oh!

finsberg commented May 12, 2026

Uh oh!

bayswiss commented May 12, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

finsberg commented May 12, 2026

Uh oh!

bayswiss commented May 12, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jorgensd commented May 14, 2026

Uh oh!

bayswiss commented May 15, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jorgensd commented May 15, 2026

Uh oh!

bayswiss commented May 6, 2026•
edited
Loading

bayswissMay 12, 2026•
edited
Loading

bayswiss commented May 12, 2026•
edited
Loading

bayswiss commented May 12, 2026•
edited
Loading

bayswiss commented May 15, 2026•
edited
Loading

bayswiss commented May 6, 2026•
edited
Loading

bayswissMay 12, 2026•
edited
Loading

bayswiss commented May 12, 2026•
edited
Loading

bayswiss commented May 12, 2026•
edited
Loading

bayswiss commented May 15, 2026•
edited
Loading

bayswiss commented May 6, 2026•
edited
Loading

bayswissMay 12, 2026•
edited
Loading

bayswiss commented May 12, 2026•
edited
Loading

bayswiss commented May 12, 2026•
edited
Loading

bayswiss commented May 15, 2026•
edited
Loading