Implementation of domains, meshes, and quadrature

[maltezfaria]

This PR implements the basic functionality to talk about some general meshes and domains, as well as to import a mesh from gmsh. It uses package extensions to not depend directly on the Gmsh package.

Tasks:

• Add a way to export the meshes to vtk
• Maybe enable direct visualization using Makie?
• Import domains and meshes from gmsh
• Generate a quadrature from a mesh and reference quadrature rules

[codecov]

Codecov Report

Attention: 193 lines in your changes are missing coverage. Please review.

Comparison is base (afb413b) 54.77% compared to head (0f66574) 63.61%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main       #4      +/-   ##
==========================================
+ Coverage   54.77%   63.61%   +8.83%     
==========================================
  Files           5       12       +7     
  Lines         199      698     +499     
==========================================
+ Hits          109      444     +335     
- Misses         90      254     +164     

Files	Coverage Δ
ext/IntiVTKExt.jl	100.00% <100.00%> (ø)
src/Inti.jl	100.00% <ø> (ø)
src/reference_integration.jl	84.21% <ø> (+14.64%)	⬆️
src/reference_interpolation.jl	40.69% <60.00%> (+16.30%)	⬆️
src/reference_shapes.jl	76.19% <0.00%> (-23.81%)	⬇️
src/utils.jl	87.80% <84.84%> (-12.20%)	⬇️
src/quadrature.jl	81.03% <81.03%> (ø)
src/mesh.jl	80.24% <80.24%> (ø)
src/domain.jl	58.53% <58.53%> (ø)
src/entities.jl	58.33% <58.33%> (ø)
... and 2 more

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[maltezfaria]

@tanderson92 The first draft is now ready to be looked at. Not perfect, but it does allow us to use gmsh and visualize things using makie. Let me know if you need help exporting to vtk.

[tanderson92]

@maltezfaria There is now VTK support. I have the transition of VTK to an extension half-done, will try to understand the errors I'm seeing with fresh eyes tomorrow (your today).

[tanderson92]

@maltezfaria Perhaps I am doing something wrong but I don't like the type piracy enforced by extensions. In order to have "function Inti.vtk_mesh_file" be allowed I need to define a stub somewhere in src/ -- I chose mesh.jl -- but then the Documenter doesn't look like it'll pick up the docstrings (unless I place the documentation in mesh.jl ?). It's all a bit awkward.

[maltezfaria]

@maltezfaria Perhaps I am doing something wrong but I don't like the type piracy enforced by extensions. In order to have "function Inti.vtk_mesh_file" be allowed I need to define a stub somewhere in src/ -- I chose mesh.jl -- but then the Documenter doesn't look like it'll pick up the docstrings (unless I place the documentation in mesh.jl ?). It's all a bit awkward.

I agree with you: this feels hacky. I will find a workaround to have:

• The functions related to an extension declared and documented inside the extension modules.
• A public API, in the namespace of Inti.jl, for using methods declared inside an extension.

[maltezfaria]

@tanderson92 Take a look at the changes I proposed and see what you think.

I tried to make the extensions as truly independent modules. The upside, IMO, is that it makes more sense how the code is structured, and who owns what. The downside is that the user now has to explicitly load the extension module, and use it in order to interact with the functionality. We could eventually add some boilerplate code so that the user only interacts through Inti.something, but I did not bother for now.

[tanderson92]

Interesting. I hope that Extensions support will change in the future as people hit these kinds of issues. It's a strange language design to consider an extension part of a module but require this explicit shadow function declaration.

It all looks good to me.

[maltezfaria]

I will go ahead and merge this soon. I am in the process of adding quadratures.

[maltezfaria]

Interesting. I hope that Extensions support will change in the future as people hit these kinds of issues. It's a strange language design to consider an extension part of a module but require this explicit shadow function declaration.

I agree with you. It should, at the very least, be better documented. Currently, my model of an extension is very sketchy: it looks syntactically like a module, but the semantics are more nuanced. If we are unhappy with the current usage because e.g. there are too many namespaces for the user to handle, we can create some wrappers in Inti.jl and document them extensively.