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

**URL:** <https://discourse.julialang.org/t/ann-gridap-jl-a-feature-rich-finite-element-ecosystem-100-in-julia/42824>\
**Category:** Package Announcements\
**Tags:** package, announcement, pde, fem\
**Created:** [July 10, 2020, 5:59am UTC](https://discourse.julialang.org/t/ann-gridap-jl-a-feature-rich-finite-element-ecosystem-100-in-julia/42824 "2020-07-10T05:59:30Z")\
**Posts on this page:** 20\
**Page:** 2

<div class="post-metadata">

**Author:** ![dpsanders](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/dpsanders/32/3573_2.png) [@dpsanders](https://discourse.julialang.org/u/dpsanders)\
**Post date:** [July 15, 2020, 10:44pm UTC](https://discourse.julialang.org/t/ann-gridap-jl-a-feature-rich-finite-element-ecosystem-100-in-julia/42824/21 "2020-07-15T22:44:21Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![klaff](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/klaff/32/7637_2.png) [@klaff](https://discourse.julialang.org/u/klaff)\
**Post date:** [July 16, 2020, 5:11am UTC](https://discourse.julialang.org/t/ann-gridap-jl-a-feature-rich-finite-element-ecosystem-100-in-julia/42824/22 "2020-07-16T05:11:59Z")

</div>

I’m guessing it’s this: “Gridap provides a set of tools for the **grid** -based **ap** proximation of partial differential equations (PDEs) written in the [Julia programming language](https://julialang.org/).”

---

<div class="post-metadata">

**Author:** ![johnh](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/johnh/32/3615_2.png) [@johnh](https://discourse.julialang.org/u/johnh)\
**Post date:** [July 16, 2020, 7:18am UTC](https://discourse.julialang.org/t/ann-gridap-jl-a-feature-rich-finite-element-ecosystem-100-in-julia/42824/23 "2020-07-16T07:18:25Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![fverdugo](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/fverdugo/32/9446_2.png) [@fverdugo](https://discourse.julialang.org/u/fverdugo)\
**Post date:** [July 16, 2020, 8:40am UTC](https://discourse.julialang.org/t/ann-gridap-jl-a-feature-rich-finite-element-ecosystem-100-in-julia/42824/24 "2020-07-16T08:40:43Z")

</div>

Try:

pkg\> build GridapGmsh

If it does not work, take a look into

[https://github.com/gridap/GridapGmsh.jl/blob/master/deps/build.jl](https://github.com/gridap/GridapGmsh.jl/blob/master/deps/build.jl)

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

---

<div class="post-metadata">

**Author:** ![B\_W\_Harris](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/b_w_harris/32/4112_2.png) [@B\_W\_Harris](https://discourse.julialang.org/u/B_W_Harris)\
**Post date:** [July 16, 2020, 3:47pm UTC](https://discourse.julialang.org/t/ann-gridap-jl-a-feature-rich-finite-element-ecosystem-100-in-julia/42824/25 "2020-07-16T15:47:17Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![B\_W\_Harris](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/b_w_harris/32/4112_2.png) [@B\_W\_Harris](https://discourse.julialang.org/u/B_W_Harris)\
**Post date:** [July 16, 2020, 4:03pm UTC](https://discourse.julialang.org/t/ann-gridap-jl-a-feature-rich-finite-element-ecosystem-100-in-julia/42824/26 "2020-07-16T16:03:09Z")

</div>

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

```julia
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:

 ![repl-fail](https://global.discourse-cdn.com/julialang/original/3X/a/a/aa9049d8e00c6fd55d920f5d405682abae87c864.png)

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

Any ideas on this one?

---

<div class="post-metadata">

**Author:** ![fverdugo](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/fverdugo/32/9446_2.png) [@fverdugo](https://discourse.julialang.org/u/fverdugo)\
**Post date:** [July 17, 2020, 6:20am UTC](https://discourse.julialang.org/t/ann-gridap-jl-a-feature-rich-finite-element-ecosystem-100-in-julia/42824/27 "2020-07-17T06:20:28Z")

</div>

I think this is related with this issue

[https://github.com/gridap/Gridap.jl/issues/286](https://github.com/gridap/Gridap.jl/issues/286)

---

<div class="post-metadata">

**Author:** ![Nathan\_Boyer](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/nathan_boyer/32/14825_2.png) [@Nathan\_Boyer](https://discourse.julialang.org/u/Nathan_Boyer)\
**Post date:** [July 20, 2020, 12:24pm UTC](https://discourse.julialang.org/t/ann-gridap-jl-a-feature-rich-finite-element-ecosystem-100-in-julia/42824/28 "2020-07-20T12:24:57Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![B\_W\_Harris](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/b_w_harris/32/4112_2.png) [@B\_W\_Harris](https://discourse.julialang.org/u/B_W_Harris)\
**Post date:** [July 20, 2020, 5:41pm UTC](https://discourse.julialang.org/t/ann-gridap-jl-a-feature-rich-finite-element-ecosystem-100-in-julia/42824/29 "2020-07-20T17:41:23Z")

</div>

Yes, that fixed it. Thanks.

---

<div class="post-metadata">

**Author:** ![PetrKryslUCSD](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/petrkryslucsd/32/215825_2.png) [@PetrKryslUCSD](https://discourse.julialang.org/u/PetrKryslUCSD)\
**Post date:** [July 20, 2020, 11:08pm UTC](https://discourse.julialang.org/t/ann-gridap-jl-a-feature-rich-finite-element-ecosystem-100-in-julia/42824/30 "2020-07-20T23:08:41Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![Nathan\_Boyer](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/nathan_boyer/32/14825_2.png) [@Nathan\_Boyer](https://discourse.julialang.org/u/Nathan_Boyer)\
**Post date:** [July 21, 2020, 12:34pm UTC](https://discourse.julialang.org/t/ann-gridap-jl-a-feature-rich-finite-element-ecosystem-100-in-julia/42824/31 "2020-07-21T12:34:48Z")

</div>

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?**

---

<div class="post-metadata">

**Author:** ![Pbellive](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/pbellive/32/3604_2.png) [@Pbellive](https://discourse.julialang.org/u/Pbellive)\
**Post date:** [July 21, 2020, 4:09pm UTC](https://discourse.julialang.org/t/ann-gridap-jl-a-feature-rich-finite-element-ecosystem-100-in-julia/42824/32 "2020-07-21T16:09:38Z")

</div>

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:

> [@fverdugo](#):
>
> > Last time I tried, I remember there was no easy way to create the grid without importing a mesh-file (relying on gmsh). Do you consider domain specification and meshing out of scope for your package or have you considered adding some primitives there? I realize `GridapGmsh` covers this somewhat but it seems more like a low-level interface to gmsh.
> 
> Mesh generation is definitively out-of-scope. We only provide a simple Cartesian mesh generator for convenience. Unstructured grids are generated elsewhere. If you have a `msh` file generated with GMSH, then you can read it with function `GmshDiscreteModel` provided by the [GridapGmsh.jl](https://github.com/gridap/GridapGmsh.jl) package (we have tested for linear triangles and tets). The other option is to avoid generating unstructured meshes and use embedded FEM. This can be done with [GridapEmbedded.jl](https://github.com/gridap/GridapEmbedded.jl). Here, you can specify your geometry as bolean operations between simple shapes.

---

<div class="post-metadata">

**Author:** ![fverdugo](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/fverdugo/32/9446_2.png) [@fverdugo](https://discourse.julialang.org/u/fverdugo)\
**Post date:** [July 22, 2020, 6:28am UTC](https://discourse.julialang.org/t/ann-gridap-jl-a-feature-rich-finite-element-ecosystem-100-in-julia/42824/33 "2020-07-22T06:28:28Z")

</div>

> [@Nathan\_Boyer](#):
>
> 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?**

Gridap is a toolbox rather than an app that provides pre-backed Finite Element solvers for solving a specific PDE. The user writes a Julia scrip that combines the tools in Gridap to solve a particular problem.

---

<div class="post-metadata">

**Author:** ![GregVernon](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/gregvernon/32/5611_2.png) [@GregVernon](https://discourse.julialang.org/u/GregVernon)\
**Post date:** [July 23, 2020, 3:15am UTC](https://discourse.julialang.org/t/ann-gridap-jl-a-feature-rich-finite-element-ecosystem-100-in-julia/42824/34 "2020-07-23T03:15:44Z")

</div>

@PetrKryslUCSD, I’ll take a stab at listing what I would consider practical (to me) engineering problems.

1. [Sections 4.1, 4.2, 5.1, 5.2](https://www.osti.gov/servlets/purl/1596201)
2. [Problem 1.6 “Ball Bearing Pull”](https://www.osti.gov/servlets/purl/1608083)
3. [Section 3.2 “Resistance Forge Weld Problem”](https://www.osti.gov/servlets/purl/1601326)

I don’t necessarily expect any Julia FEM package to solve these problems - rather I’d expect a commercial/government code (possibly written in Julia) to solve these problems.

---

<div class="post-metadata">

**Author:** ![PetrKryslUCSD](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/petrkryslucsd/32/215825_2.png) [@PetrKryslUCSD](https://discourse.julialang.org/u/PetrKryslUCSD)\
**Post date:** [July 23, 2020, 3:22am UTC](https://discourse.julialang.org/t/ann-gridap-jl-a-feature-rich-finite-element-ecosystem-100-in-julia/42824/35 "2020-07-23T03:22:28Z")

</div>

I don’t doubt that these are tough problems, that fit well the definition of a practical engineering problem. But, not all practical engineering problems are this complicated. There’s a spectrum.

I’m not sure why anyone would expect an open source code, with a handful of people working on it in their free time, to attack problems that thoroughly exercise codes such as Sierra (to which you linked), developed by hundreds of man years, with budget probably on the order of $1 million per year.

Could a commercial code be developed in Julia, for sure. Do you have the budget for it?

PS: By the way, I believe some of your links are mixed up.

---

<div class="post-metadata">

**Author:** ![GregVernon](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/gregvernon/32/5611_2.png) [@GregVernon](https://discourse.julialang.org/u/GregVernon)\
**Post date:** [July 23, 2020, 3:35am UTC](https://discourse.julialang.org/t/ann-gridap-jl-a-feature-rich-finite-element-ecosystem-100-in-julia/42824/36 "2020-07-23T03:35:38Z")

</div>

I don’t expect any open-source _toolbox_ to handle these problems. I’ve thoroughly enjoyed watching various open-source toolboxes (FEniCS, your project, MFEM, etc) grow and develop. But you asked for comments on what people might consider practical, so I felt compelled 😉 . I personally think we’re lucky to have _any_ open-source FEM tooboxes (and _incredibly_ lucky to have the [MOOSE](https://www.mooseframework.org/) toolbox open-sourced by INL).

Something I’ve pondered on for quite some time is whether a large compendium of “practical” examples could be compiled, that then various toolboxes / codes could use as a capabilities reference. “Practical” here refers to the spectrum of non-verification style problems (i.e. no patch tests). Abaqus has an enormous suite of example problems that demonstrate capabilities.

Links should all work, but depending on OSTI’s servers, may take some refreshes.

### Edit:

And I do think some projects should be a little more careful in what they claim, for instance Elmer FEM claims:

> Elmer includes physical models for all branches of computational engineering and even beyond. … This is not a limitation of the code but rather limitation of time used make these examples. [https://www.csc.fi/web/elmer/application-examples](https://www.csc.fi/web/elmer/application-examples)

Yet they don’t appear to support contact in their structural mechanics code, nor structural dynamics capabilities!

---

<div class="post-metadata">

**Author:** ![PetrKryslUCSD](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/petrkryslucsd/32/215825_2.png) [@PetrKryslUCSD](https://discourse.julialang.org/u/PetrKryslUCSD)\
**Post date:** [July 23, 2020, 3:43am UTC](https://discourse.julialang.org/t/ann-gridap-jl-a-feature-rich-finite-element-ecosystem-100-in-julia/42824/37 "2020-07-23T03:43:12Z")

</div>

Second the sentiment on MOOSE.

Also like the idea of a compendium. That could become one of the features of the JuliaPDE organizations, perhaps. But, I think that verification problems are good. There are many nontrivial benchmark problems in Abaqus, and FinEtools in particular solves a good number of those.

In addition, it would be good to have more comprehensive examples, especially with multi-physics. The problem then becomes how to tell a good solution from a bad one. 😉

---

<div class="post-metadata">

**Author:** ![GregVernon](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/gregvernon/32/5611_2.png) [@GregVernon](https://discourse.julialang.org/u/GregVernon)\
**Post date:** [July 23, 2020, 4:04am UTC](https://discourse.julialang.org/t/ann-gridap-jl-a-feature-rich-finite-element-ecosystem-100-in-julia/42824/38 "2020-07-23T04:04:34Z")

</div>

Maybe let me define two kinds of verification problems (borrowing from the insights of [this VV&UQ paper](https://www.osti.gov/biblio/918370)): Code-verification, Capability-demonstration (roughly aligning to the paper’s descriptions of _weak-sense_ / _Glass-box benchmarks_ and _strong-sense / black-box benchmarks_ respectively)

Regarding code-verification problems, I agree that they’re absolutely necessary, but they are often so integral to the development of a code (and often simple) that I’m not as concerned about developers being able to build their own verification problems. (But perhaps I’m overestimating the maturity here?)

Many practical engineering problems are nonlinear and do not have closed-form solutions to verify the code’s capabilities. So I think having a freely-available compendium of practical problems where developers can provide demonstrations of their code’s applicability, workflow, accuracy, robustness, uncertainty etc. and compare against other code-bases would be most useful.

---

<div class="post-metadata">

**Author:** ![fverdugo](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/fverdugo/32/9446_2.png) [@fverdugo](https://discourse.julialang.org/u/fverdugo)\
**Post date:** [July 23, 2020, 5:27am UTC](https://discourse.julialang.org/t/ann-gridap-jl-a-feature-rich-finite-element-ecosystem-100-in-julia/42824/39 "2020-07-23T05:27:27Z")

</div>

> [@GregVernon](#):
>
> - [Sections 4.1, 4.2, 5.1, 5.2](https://www.osti.gov/servlets/purl/1596201)
> - [Problem 1.6 “Ball Bearing Pull”](https://www.osti.gov/servlets/purl/1608083)
> - [Section 3.2 “Resistance Forge Weld Problem”](https://www.osti.gov/servlets/purl/1601326)

Very nice examples!

Contact mechanics is the main missing part for solving some of these problems in Gridap. But, I believe we have the other ingredients: multi-physics, non-linear, time-dependent, history-dependent, etc.

---

<div class="post-metadata">

**Author:** ![fverdugo](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/fverdugo/32/9446_2.png) [@fverdugo](https://discourse.julialang.org/u/fverdugo)\
**Post date:** [July 23, 2020, 5:30am UTC](https://discourse.julialang.org/t/ann-gridap-jl-a-feature-rich-finite-element-ecosystem-100-in-julia/42824/40 "2020-07-23T05:30:19Z")

</div>

> [@GregVernon](#):
>
> Something I’ve pondered on for quite some time is whether a large compendium of “practical” examples could be compiled, that then various toolboxes / codes could use as a capabilities reference. “Practical” here refers to the spectrum of non-verification style problems (i.e. no patch tests). Abaqus has an enormous suite of example problems that demonstrate capabilities.

It would be very nice to have this list and see how different FE libraries perform for each case. I am sure that there will be libraries that work better for some problems and viceversa.

[Previous page](https://discourse.julialang.org/t/ann-gridap-jl-a-feature-rich-finite-element-ecosystem-100-in-julia/42824.md?page=1)

[Next page](https://discourse.julialang.org/t/ann-gridap-jl-a-feature-rich-finite-element-ecosystem-100-in-julia/42824.md?page=3)