Ferrite.jl release announcements

I would like to start this thread for Ferrite.jl release announcements. However, since this package have not been properly announced in this forum to begin with, so I guess I should do that first.

Ferrite.jl: A finite element library for Julia

Links: Ferrite.jl code repository, Ferrite.jl documentation.

Ferrite.jl is a library for finite element analysis in Julia. It has been around since 2016, but it dwelled in the shadows of unregisteredness back then under the name JuAFEM.jl. Around two years ago, after gaining some developers and users, we changed the name, and finally registered it.

Ferrite.jl shares some similarities (at least in spirit) with the C++ library deal.ii. It provides the “puzzle pieces” of a typical FEM program, for example:

  • Grid/mesh functionality
  • Degree of freedom distribution
  • Finite element “kernel” functionality (evaluation of values, gradients, etc, of shape functions, numerical quadrature, …)
  • Global assembly routines
  • Constraint and boundary condition handling (e.g.Dirichlet, Neumann, and periodic boundary conditions, general affine constraints)
  • Postprocessing (evaluating primary and secondary quantities, export data)

One of the core ideas of Ferrite.jl is that you can pick and chose which pieces you use, and which ones your want to bring yourself. This means that Ferrite.jl composes nicely with other packages in the Julia ecosystem. For example, BlockArrays.jl for blocked local and/or global arrays, DifferentialEquations.jl/SciML stack for time integration, Tensors.jl for automatic differentiation and material modeling, ForwardDiff.jl for computing element tangents, etc.

For a more detailed overview you can have a look at my presentation from the Ferrite.jl User & Developer Conference that we organized in September of 2022 (see the program for other interesting presentations).

The documentation include a bunch of examples which showcases how Ferrite.jl can be used, and how it can be combined with other parts of the ecosystem.

If you have any questions about Ferrite.jl, a bunch of users and developers are hanging out in the #ferrite-fem channel on the Julia slack workspace and we are happy to help you out!

Release announcements for releases 0.3.2 – 0.3.11

Since about a year (actually, exactly one year on the day) we have recorded changes in a CHANGELOG* and now include the changes for releases 0.3.2 to 0.3.11. If you are interested in what we have been working on, please scroll through it! I personally think that a lot of cools tuff have been added over the last year, and there are many exciting things still in the works.

As I mentioned in the beginning, this thread will be used to post future release announcements as well, so if you are curious, feel free to follow along!

*Sidenote, but I wich this is something more packages did. Ferrite.jl uses the keep a changelog format, which I find quite nice. It takes a bit getting used to adding a note in the changelog for changes, but it is very valuable for consumers of your package!


Ferrite version 0.3.12

New release, with various bugfixes, see CHANGELOG.md for details.


I am a new user of Ferrite.
I am interested mainly assembly of stiffness matrix with Ferrite. I converted my test mesh in Grid format. Then, generated a Dofhandler. I have single scalar field for solution. However I noticed that celldofs for each cell/elements are different my original mesh nodes.
For eg. original mesh element number 1 = [1 2 5], the corresponding celldofs from generated doflhandler is [1 2 3].
This creates an issue, as I am assembling some field/source vectors outside of Ferrite with original mesh node numbering.

Any suggestions will be helpful.


Indeed, the numbering of DoFs and nodes are completely independent. Here is a function that renumbers the DoFs to match the node numbering (obviously only works if you only have DoFs in nodes etc):

function renumber_to_node_order!(dh::DofHandler)
    perm = zeros(Int, ndofs(dh))
    for c in CellIterator(dh)
        perm[c.dofs] = c.nodes
    renumber!(dh, perm)
    return dh

Thanks it worked now; tried with quadrilateral triangles.
Next will try multithreading.

In addition to Ferrite.jl, my colleague Dennis Ogiermann and I have been working on FerriteViz.jl. Yesterday, we released the new version 0.2.0 with cool new features. FerriteViz.jl was born due to the need of visualizing finite element results computed with Ferrite.jl in notebooks. I have converted a lot of educational material from Fortran coding to interactive Pluto notebooks and I thought it would be cool to have interactive finite element plots in there, because there is a lot to learn when visualizing finite element solutions! These days I also use it for prototyping research code/ visualizing prototype problems before running them on a cluster. My long term goal is to never leave my Julia REPL (except for the Makie window next to it).

As of now, we can do a lot of things that can be achieved with ParaView and we even have some unique selling points!

Let’s talk first about the things that are on par with ParaView:

  • glyph filter from paraview => arrows in FerriteViz.jl
  • warp by scalar filter from paraview => surface in FerriteViz.jl
  • classic contour plots of FE fields in ParaView => solutionplot in FerriteViz.jl
  • plot of cell/elementwise constant data => cellplot in FerriteViz.jl
  • wireframe plots the finite element mesh and optionally labels of nodes and cells as well as showing cellsets in the underlying Ferrite.Grid
  • clip => currently we only have a CrinkleClip implementation, but more elaborate clipping algorithms will follow

All of the mentioned plot types are just Makie Recipes and thus, you can combine, mix and customize them as you normally would do with Makie plots. To showcase this, we included a small “ferriteviewer” which is a minimal interactive viewer suitable for structural mechanics problems in FerriteViz.jl. Take the viewer with a grain of salt, as it is only intended to show what you can do with the underlying plotting methods. If you would like to see it in action, take a look at the docs, especially the tutorial!

Things that exceed features from ParaView (at least as far as I know)

Things that are currently missing, but will probably be added later

  • nonlinear deformation and geometry
  • visualization of boundary conditions
  • subdomain entity plotting, e.g. facesets, edgesets, vertexsets and nodesets
  • occlusion culling to make large 3D meshes feasible
  • visualization of stresses/fluxes that are results of so called internal variables (or in general direct visualization of high order tensor data)
  • proper mixed grid supports for fields by Ferrite.MixedDofHandler as soon as Ferrite.DofHandler and Ferrite.MixedDofHandler are merged™

We would be very happy if you give it a try, report any bugs you find, give us feedback or get in touch with us if you have any suggestions for improvements!


I wonder if these parallel efforts to visualize fields over meshes could be joined into a single stream. MeshViz.jl is very sophisticated already and it seems that we are missing an opportunity to reuse mesh types across different finite element projects:


That sounds intriguing! Do you think there is potential to use this for discontinuous Galerkin methods implemented in Trixi.jl as well?

Definitely, since we designed the underlying machinery specifically for discontinuous plotting (which already starts for cell-wise constant data). Dennis did a PR back then that changed the underlying tessellation from a “classic” triangle tessellation to an L2-kind of tessellation where the triangles don’t share a node. This gives us the flexibility to visualize cellwise constant data and other more specialized types of elements like Crouziex-Raviart or discontinuous fields in general. I don’t know off the top of my head if there is a hard limitation in terms of chosen element, but I would tend to say no, as long as we can evaluate the shape functions at the nodes and approximate it by some refinement and piecewise discontinuous linear shape functions.

I’m looking forward to making things more performant, so that they can be used more in the research use case (by means of occlusion culling, custom kernels for GPU,…). For teaching, I’d say that the package works as is (at least for the problems we look at in our exercises).

We’ve gained some experience, and I think it was essential. With this experience, I would say that in the future it’s possible to write a generic interface for finite element frameworks using the same visualization package. For now, we still have to figure things out and we could only provide a quick and dirty solution if you give us a dof vector from Trixi.jl and a grid so that we translate it into a Ferrite.DofHandler and then you could instantiate a plotter as usual

Edit: I thought you already had some nice visualization stuff for Makie here: Trixi.jl/src/visualization at main · trixi-framework/Trixi.jl · GitHub What is missing there?

Thanks! Well, we already have something made specifically for us, but it would be nice to share more code and benefit from the work of others. For example, we do not have the bandwidth to do some custom GPU programming for visualization at the moment.

If you think it would be helpful for you to experiment with the kind of data we have, we would be happy to talk to you. Otherwise, I will probably wait a bit and let you develop new cool features :slightly_smiling_face:

Ferrite version 0.3.13

I want to highlight a couple of things in this release:

  • New functionality for wedge/prism elements by @termi-official (Ferrite-FEM/Ferrite.jl#581). This required quite some changes to the code base since we previously assumed uniform degree-of-freedom distribution on all entities (edges, faces, …). These changes will make it easier to implement other element types in the future, such as e.g. pyramid elements for which there is already a WIP PR by @lijas (Ferrite-FEM/Ferrite.jl#623).
  • New Developer documentation section in the manual for documenting Ferrite.jl internals and developer tools. Not everything is documented here yet, but it is a start and hopefully it will help new developers get up to speed.

See CHANGELOG.md for all changes and more details.


Ferrite version 0.3.14

For this release we have been focusing on feature and performance parity between the MixedDofHandler and the DofHandler.

For the uninitiated this might require some additional context. For some years we have been maintaining two degree-of-freedom-handlers: The original one called DofHandler and a later addition called MixedDofHandler. The MixedDofHandler is more flexible and can handle i) different element types and ii) different unknown fields on different subdomains. Up until now the MixedDofHandler have not been able to keep up performance wise with the DofHandler. But with this release they perform equally good, where it matters. This means that in a future release we will remove the current implementation of DofHandler and rename MixedDofHandler to DofHandler since there is no need to maintain the old one when we have an alternative that is more capable and equally performant.

See CHANGELOG.md for all changes and more details.


FerriteViz version 0.2.1

In this release a lot of performance improvements have been done. Some highlights of the release:

  • support for MixedDofHandler and therefore visualization of fields that only live on a subdomain
  • basic culling so that fields are only rendered on the boundary elements of the domain
  • ShaderAbstractions.Buffer usage for faster solution vector updates/rendering

The new release in action with a fork of FerriteCohesiveZones:
cohesive zone model

See the CHANGELOG.md for all changes and links to PRs with more details.


FerriteViz version 0.2.2

This release of FerriteViz contains mostly internal changes. Release highlights are:

  • uniform refinement of triangulations for high order visualization
  • update to latest Makie and Documenter release
  • several bug fixes for corner cases

See the CHANGELOG.md for all changes and links to PRs with more details.