Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Gmsh Python API #180

Closed
gdmcbain opened this issue May 10, 2019 · 7 comments
Closed

Gmsh Python API #180

gdmcbain opened this issue May 10, 2019 · 7 comments

Comments

@gdmcbain
Copy link
Contributor

I've been experimenting with the new Gmsh Python API, in conjunction with the wrapping package gmsh-sdk. It's good.

So far, I've just been using it to generate MSH files for Mesh.load, but of course part of the appeal is that it might be possible to avoid writing out the mesh and rereading it (as is necessary for pygmsh); i.e. it should be possible to instantiate a skfem.Mesh directly from the data structures available in the Gmsh Python API. This would bypass not only Mesh.load but also Mesh.from_meshio.

In order to pass on any subdomains and boundaries, should it populate Mesh.external and then use Mesh._parse_submeshes as Mesh.from_meshio does?

Or (thinking also of the impasse on loading MeshLine.boundaries in #175) should the skfem.Mesh constructors be enhanced to take not only points and cells but also optionally subdomains and boundaries? Factoring that code out of Mesh._parse_submeshes.

@kinnala
Copy link
Owner

kinnala commented May 16, 2019

Do you happen to have a minimal example so I can try it out?

@kinnala
Copy link
Owner

kinnala commented May 16, 2019

Nevermind, I found some stuff here: https://gitlab.onelab.info/gmsh/gmsh/blob/master/demos/api/adapt_mesh.py

@kinnala
Copy link
Owner

kinnala commented May 16, 2019

Maybe the cleanest way of doing this would be along

Or (thinking also of the impasse on loading MeshLine.boundaries in #175) should the skfem.Mesh constructors be enhanced to take not only points and cells but also optionally subdomains and boundaries? Factoring that code out of Mesh._parse_submeshes.

Basically we'd be writing various functions that take some external Mesh format object and transform those into a tuple of correct input variables for Mesh.__init__.

Some questions:

  • How Mesh.load and Mesh.save fit into this picture?
  • Where these importers should reside? New module or utils or something else?

@gdmcbain
Copy link
Contributor Author

I've just noticed that gmsh-sdk is actually also a convenient way of installing Gmsh itself

pip install gmsh-sdk
which gmsh

/home/geordie/.local/share/miniconda3/envs/scikit-fem/bin/gmsh

gmsh -version

4.5.1.

This might replace the three lines

scikit-fem/.travis.yml

Lines 8 to 10 in 55bcfc7

- wget http://gmsh.info/bin/Linux/gmsh-4.3.0-Linux64.tgz
- tar zvxf gmsh-4.3.0-Linux64.tgz
- sudo cp gmsh-4.3.0-Linux64/bin/gmsh /usr/bin

Also is this fourth already redundant?

- sudo apt-get install gmsh

@gdmcbain
Copy link
Contributor Author

A brief example of a Python script importing gmsh to open a MSH file and read the nodal coordinates was posted by C. Geuzaine 2020-01-13 in the Gmsh thread ‘Transforming mesh’; this might be a starting point for a future skfem.importers.gmsh.from_file module function.

@kinnala
Copy link
Owner

kinnala commented Sep 14, 2020

gmsh is GPL so cannot depend on it.

@kinnala kinnala closed this as completed Sep 14, 2020
@gdmcbain
Copy link
Contributor Author

This might be coming back in via nschloe/pygmsh#360.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants