meshmode
meshmode copied to clipboard
inducer
Interface with meshio
Coreform Cubit can write mesh files in NASTRAN format, I have created a simple translation tool to go from NASTRAN to GMSH, which meshmode can already read, but it would be better to directly read in NASTRAN.
Here is my script that converts a NASTRAN file into a gmsh format. https://gist.github.com/anderson2981/a16c045288401a55d450e3a831896cd9
Here an example 2D NASTRAN example. https://gist.github.com/anderson2981/97f9a16c3f2828cae9e0c1e039beedbc
One problem I see here is that human-readable names (e.g. wall_block) occur only in lines that are technically comments. How important is it that these names are preserved?
https://victorsndvg.github.io/FEconv/formats/bdf/MD_Nastran_2006_Quick_Reference_Guide.pdf
(Compared to just the property numbers, i.e. the things defined by PROD et al.)
I use the names as tags to apply the boundaries in my driver, so while the actual name isn't important, I still need some way of telling the driver which boundary is which. Gmsh has an extra section that defines all the names and their assignments.
This is an updated version of what I sent last week. To get the names I just read all the comment lines in the property section to figure out what the names are.
https://gist.github.com/anderson2981/1fb6d9d7d79002e3b3430af9c55c3a20
A bit unrelated, but is meshio still an option at all? It's not very maintained anymore, but I imagine the established formats work pretty well. Shouldn't be too hard to write a little meshio2meshmode wrapper and that will give access to a whole bunch of formats (including NASTRAN).
as far as i can tell, meshio does not appear to be an export format supported by coreform. Which is driving this development.
as far as i can tell, meshio does not appear to be an export format supported by coreform. Which is driving this development.
meshio is just a library that can read and write a bunch of formats (including NASTRAN). I was suggesting to use it so that we don't have to implement the parsing ourselves. (more of a question, than a suggestion though)
@lukeolson and I discussed that a bit a few years ago, and at the time
- we didn't need it because Gmsh covered our needs, and
- Nico Schloemer (sp?), the maintainer of meshio, had established a track record of closed-sourcing his packages (now branded as https://github.com/sigma-py/)
which led us to dismiss the possibility. At the same time, :shrug: if it gets closed up, we can just continue life with a fork. (e.g. https://github.com/inducer/meshio) So... maybe this is less bad than hacking our own half-broken NASTRAN reader.