Ferrite.jl release announcements

Package Announcements
,
1

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!

42 Likes
2

Ferrite version 0.3.12

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

2 Likes
3

Hi,
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.

Thanks

4

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
    end
    renumber!(dh, perm)
    return dh
end
5

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

6

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!

7 Likes
7

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:

2 Likes
8

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

9

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?

10

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:

11

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.

3 Likes
12

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.

4 Likes
13

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.

5 Likes
14

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.

2 Likes
15

Hello Fredrik,
i am currently working on a project in Ferrite in implementing the arc length method with it being a transition between two simulations (one being compression and arching of a beam, second being fixing the beam and applying force downwards to cause a snapthrough), and have an issue in switching the faceset in the transition where my force is acting (while also changing the acting Force).
as i cannot alter or overwrite the faceset using pointers, nor can i redefine the faceset with the same name after it has already been defined, would it be somehow possible to remove a faceset after a certain number of increments or iterations or even alter it?

16

Ferrite version 1.0.0

image
image814Ă—366 53.9 KB

Reactant concentration field from solving the Gray-Scott model with embedded elements on a spherical surface (see tutorial)

It has been a long time coming but finally Ferrite version 1.0.0 has been released :tada:.

The last release (version 0.3.14) is almost 1.5 years ago and there have been lots and lots of changes to the package since then. The CHANGELOG.md documents all changes, and also include instructions for how to upgrade from the 0.3.x release series to the 1.x one. Almost all breaking changes have deprecation errors and you should be able to run Ferrite 0.3 code with this new release and fix errors one by one to upgrade.

I want to highlight a few of the changes here:

  • The documentation have been reworked. It is now split into four major parts[1]: Tutorials, Topic guides, API reference, and How-to guides. In addition there is also a Code gallery and Developer documentation.
  • It is now possible to iterate and integrate over interfaces between elements which is needed for discontinuous Galerkin methods. This is the result of last years GSoC project by @AbdAlazezAhmed. See the tutorial on discontinuous Galerkin heat equation and the presentation from last years FerriteCon for more details.
  • It is now easier to work with subdomains of the grid. This functionality was partially there already in previous releases but is now fully supported. @kimauth spearheaded this work and also presented this development during last years FerriteCon.
  • It is now easier to iterate and integrate boundary integrals. This was supported before as well, but it is now consistent with how iterating/integrating cells and interfaces work (contributed by @KnutAM).
  • Lots and lots of internal changes (mainly by @KnutAM, @termi-official, and @lijas) that generalizes and “future proofs” the code base such that many new features can be added in a non breaking way. This already enabled embedded elements (for example 2D elements in 3D space as in the image at the top of this post) and will enable enable H(curl) and H(div) spaces (WIP PR), among other things, in future releases.
  • Sparsity pattern creation have been modularized. Previously Julia’s default sparse matrix, SparseMatrixCSC from SparseArrays.jl, was always assumed but after this rework it is much easier to interface with other sparse matrix libraries and solvers. See for example this PR for HYPRE.jl support and this PR for SparseMatricesCSR.jl support.

Thanks to everyone who contributed!

  1. Following the Diátaxis Framework ↩︎

23 Likes
17

Out of curiosity I did a search on “Julia FEM” and came across “https://www.juliafem.org/”. However I did not see Ferrite mentioned there. Is this an oversight?

18

JuliaFEM is a separate effort which I think is abandonded or stalled (at least for now).

19

Really nice release, will try out to implement Local DG method (see https://www.global-sci.org/v1/cicp/openaccess/v7_1.pdf for instance if curious) in it and test the new face-iteration possibility because I’m not a big fan of how Trixy works and kinda abandoned doing it. Need to find a way to solve element-wise instead of assemble or use block matrix which should have same performances.

Thank you for the insane work !

3 Likes