[ANN] Gridap.jl: A feature-rich Finite Element ecosystem 100% in Julia

I don’t know if I have understood it correctly, but I think this is not true. Finite element types are not hard-coded. The code is implemented in terms of an abstract type called ReferenceFE which can be extended with custom user-defined concrete implementations. It is true that the library provides a default local-to-global dof map, but you can implement you own if you wish. You just need to implement a new constructor FESpaceWithMyOwnDOFMap that should return some object with a well defined interface.

Yes, you can use the linear solver you want. For instance, for the example above you can do:

op = AffineFEOperator(Ug,V0,t_Ω,t_Γ)
A = get_matrix(op)
b = get_vector(op)
x = A\b # Solve this with your favorite linear solver
uh = FEFunction(Ug,x)
writevtk(trian_Ω,"results",cellfields=["uh"=>uh])

I noticed that at least one member of this forum found Gridap.jl in the PDE-software list
prior to this announcement!

That is great, and so I would like to invite all of you: include your work in the list, it seems to provide good exposure. Your software may come in handy in someone else’s work. Do let them know of its existence. File an issue, or open a PR.
Thanks,
P

11 Likes

Amazing work! Thank you for this great contribution Gridap.jl authors!

I’d like to jump in and share another standardization effort that is ongoing regarding meshes for FEM, spatial modeling and visualization: https://github.com/JuliaGeometry/GeometryBasics.jl/issues/15

A prototype a la Tables.jl is being sketched in Meshes.jl. Ultimately, we would like to benefit from a common interface so that we can operate on mesh objects within different frameworks.

7 Likes

This seems like a very nice package with good documentation and tutorials. Thank you.

I’ve run through the tutorial set without trouble. However, when I attempt create my own model.json file, as described in Tutorial 1 notebook as:

“The file "model.json" is a regular json file that includes a set of fields that describe the discrete model. It was generated by using together the GMSH mesh generator and the GridapGmsh package. First, we generate a "model.msh" file with GMSH (which contains a FE mesh and information about user-defined physical boundaries in {GMSH} format). Then, this file is converted to the Gridap-compatible "model.json" file using the conversion tools available in the GridapGmsh package. See the documentation of the GridapGmsh for more information.”

I get stuck at the GridapGmsh step. I don’t see any tools in there (documentation or source code) to perform the conversion. Can you point me in the right direction?

Thanks for the interest! Try this:

using Gridap
using Gridap.Io
using GridapGmsh

model = GmshDiscreteModel(“model.msh”)

fn = “model.json”
to_json_file(model,fn)

1 Like

Ah yes thank you. That’s the kick I needed. I see now that it’s in the tutorial/models folder for each of the model .jl files.

Nice that it helps!

BTW, you can use the object “model” directly in your computation without writing it to json and reading it again. We only use the json file in the tutorials as a way of avoinding to force the users to install gmsh.

Looks very nice! What does the package name mean? I think I get “grid”, but not “ap”.

1 Like

I’m guessing it’s this: “Gridap provides a set of tools for the grid-based approximation of partial differential equations (PDEs) written in the Julia programming language.”

1 Like

I have installed gmsh but I get

julia> model=GmshDiscreteModel(“demo.msh”)
ERROR: GridapGmsh is not loaded or installed properly.

Julia Version 1.5.0-beta1.0 (2020-05-28)
Fedora 32 Linux

$ julia ./demo/demo.jl
ERROR: LoadError: GridapGmsh is not loaded or installed properly.
Stacktrace:
[1] error(::String) at ./error.jl:33
[2] macro expansion at /home/hearnsj/.julia/packages/GridapGmsh/Kh2vV/src/GridapGmsh.jl:48 [inlined]
[3] GmshDiscreteModel(::String) at /home/hearnsj/.julia/packages/GridapGmsh/Kh2vV/src/GmshDiscreteModels.jl:7
[4] top-level scope at /home/hearnsj/julia-code/gridap/GridapGmsh.jl/demo/demo.jl:5
[5] include(::Function, ::Module, ::String) at ./Base.jl:380
[6] include(::Module, ::String) at ./Base.jl:368
[7] exec_options(::Base.JLOptions) at ./client.jl:296
[8] _start() at ./client.jl:506
in expression starting at /home/hearnsj/julia-code/gridap/GridapGmsh.jl/demo/demo.jl:5

Try:

pkg> build GridapGmsh

If it does not work, take a look into

and check if it covers your scenario. If not, you are wellcome to open a PR with a fix for your case.

To get this to work, I found that the gmsh SKD must be installed. It contains a few extra sub-directories. The /lib then contains gmsh.jl that is needed for GridapGmsh to properly build and run.

I found something strange that I can’t get around. The first three lines of Tutorial one: t001_poisson

using Gridap
model = DiscreteModelFromFile("../models/model.json")
writevtk(model,"model")

execute properly from the notebook supplied in the tutorial. However, the same code fails in the REPL:

It’s some type conversion error but I don’t see why it presents in the REPL.

Any ideas on this one?

I think this is related with this issue

Can you summarize at a high-level the capabilities of this package compared with commercial software like ANSYS or Abaqus? I realize that the commercial software are developed by much larger teams with much more money, so I do not mean to criticize your package. I just have no idea of what Julia implementations are capable. Can this package be used on moderately complex geometries to solve practical engineering problems, or is it more for tinkering and research purposes?

Specifically I am interested in:

  1. transferring geometry from Solidworks
  2. automatic unstructured meshing and mesh control
  3. frictional contact surfaces and separation detection
  4. automatic tracking of nodal/elemental locations and connections
  5. solving heat transfer and force balance simultaneously
  6. post-processing
1 Like

Yes, that fixed it. Thanks.

Define practical engineering problem. I certainly use Julia to solve (what I think of as) practical engineering problems.

I suppose my main concern would be the handling of realistic geometries. I could code up a 1D finite element solver where I manually assign all the nodes and elements fairly easily, but a 3D solver which can mesh itself and perform the appropriate quadrature is expected for most practicing engineers.

My next concern would be what problems it can solve. What PDEs are supported, and how accurate and stable are the iterations?

I suppose my queries all boil down to the following question:
On a spectrum of required user involvement from coding my own simulations using the finite element method to clicking buttons in a commercial GUI, where does this package sit, and what benefit does being situated at that position provide?

1 Like

I haven’t used Gridap and this isn’t a full answer to your question but the following post from earlier in this thread gives a partial answer:

2 Likes