search

multiphenics / multiphenicsx

multiphenicsx - easy prototyping of multiphysics problems in FEniCSx
https://multiphenics.github.io/
GNU Lesser General Public License v3.0
39 stars 7 forks source link

`dolfinx.io.gmshio` references cause errors in tutorials #9

Closed dr-kinder closed 1 year ago

dr-kinder commented 1 year ago

I see that a recent change to the repository states that "dolfinx.io.gmshio.model_to_mesh is not needed anymore" and all import statements for this module have been deleted. However, in (at least) three of the tutorials, the module is referenced during mesh generation:

mesh, subdomains, boundaries = dolfinx.io.gmshio.model_to_mesh(
    gmsh.model, comm=mpi4py.MPI.COMM_WORLD, rank=0, gdim=2)

This yields an error, and I was unable to import the model_to_mesh function from dolfinx.io.gmshio. Thus, most of the tutorials I tried do not run.

I am relatively new to multiphenicsx, so maybe there is an easy substitution for the model_to_mesh syntax. I would recommend updating the tutorials to eliminate all use of this module.

francesco-ballarin commented 1 year ago

Hi, 1) are you using a recent dolfinx version, i.e. more recent than September 10? That commit requires https://github.com/FEniCS/dolfinx/pull/2357 2) do you have gmsh installed at dolfinx import time?

To clarify, we do still use dolfinx.io.gmshio.model_to_mesh in several tutorials, and we are not going to remove it. After the upstream PR what should not be required anymore is an explicit import of dolfinx.io.gmshio, since importing dolfinx.io suffices.

dr-kinder commented 1 year ago

Thanks for the explanation, and the insightful response!

In brief:

  1. I am using version 0.5.2.0 of dolfinx
  2. I was importing dolfinx before installing gmsh.

Installing gmsh before importing dolfinx fixed the problem.

I suppose this would not normally be an issue if both dolfinx and gmsh were installed at runtime. However, I was exploring multiphenicsx within Google Colab using examples on FEM on Colab. I pasted the install codes from this notebook for multiphenicsx and this notebook for gmsh into a notebook, and then tried running examples from the tutorials here. The packages install successfully, and the import statements succeed, but when I ran the line with model_to_mesh, I got an error.

Based on your input, my issue appears to have been using the install code on the FEM on Colab without understanding the sequence of commands and dependencies thoroughly. The examples from that site attempt to import a module, and if that fails, install the module and immediately import it. Restarting the Python kernel fixed the problem, because both modules were installed before importing either.

After placing all of the install code for gmsh and dolfinx before any import statements, the tutorial examples work as intended, even in a fresh session on Google Colab.

Thanks again for the help.

francesco-ballarin commented 1 year ago

I confirm what you are saying, and indeed I was suspecting that you were using FEM on Colab.

It's actually quite nice that you got to use the multiphenicsx tutorials on there, considering that the open in Colab branch on that repo is not well advertised. I have been meaning to create a simple website for multiphenicsx that will link those tutorials on Colab, but that task has not made it to the top of my todo list yet.

For future reference: 1) if you look at the Colab versions of the remaining tutorials, e.g. https://colab.research.google.com/github/multiphenics/multiphenics.github.io/blob/open-in-colab-multiphenicsx/tutorials/02_navier_stokes/tutorial_navier_stokes.ipynb , you will see that the installation cells are in the right order: gmsh first, and fenicsx later. 2) keep in mind that the Colab installation cells on the previous notebook (i.e., all notebooks from the multiphenics.github.io repo) do hardcode fenicsx, gmsh etc to a specific FEM on Colab package release, and multiphenicsx to a specific git commit. This in contrast to the generic installation cells reported on the FEM on Colab website, that by default downloads the latest packages. Hardcoding a specific release is the safest option, which should typically guarantee that (unless Colab OS changes drastically) you could run that notebook at any time in future, and that's why I've set up multiphenicsx' Colab release workflow that way. The notebooks on multiphenics.github.io are automatically tested and updated once a week to use new FEM on Colab package releases. If you are creating you own notebooks on Colab, and don't mind the occasional breakage (e.g., because of FEniCSx upstream changes), I would personally go for the generic installation cells.