# Ferrite.jl release announcements

**URL:** https://discourse.julialang.org/t/ferrite-jl-release-announcements/93157
**Category:** Package Announcements
**Tags:** announcement, finite-element
**Created:** [January 18, 2023, 2:07pm UTC](https://discourse.julialang.org/t/ferrite-jl-release-announcements/93157 "2023-01-18T14:07:07Z")
**Posts on this page:** 20
**Page:** 1

<div class="post-metadata">

### Author: ![fredrikekre](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/fredrikekre/32/1688_2.png) [@fredrikekre](https://discourse.julialang.org/u/fredrikekre)
#### Post date: [January 18, 2023, 2:07pm UTC](https://discourse.julialang.org/t/ferrite-jl-release-announcements/93157/1 "2023-01-18T14:07:07Z")

</div>

I would like to start this thread for [Ferrite.jl](https://ferrite-fem.github.io/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](https://github.com/Ferrite-FEM/Ferrite.jl), [Ferrite.jl documentation](https://ferrite-fem.github.io/Ferrite.jl/).

[Ferrite.jl](https://ferrite-fem.github.io/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](https://www.dealii.org/). 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](https://ferrite-fem.github.io/Ferrite.jlstable/examples/incompressible_elasticity/), [DifferentialEquations.jl/SciML stack for time integration](https://ferrite-fem.github.io/Ferrite.jl/stable/examples/ns_vs_diffeq/), [Tensors.jl for automatic differentiation and material modeling](https://ferrite-fem.github.io/Ferrite.jl/stable/examples/hyperelasticity/), [ForwardDiff.jl for computing element tangents](https://ferrite-fem.github.io/Ferrite.jl/stable/examples/landau/), etc.

For a more detailed overview you can have a look at [my presentation](https://ferrite-fem.github.io/FerriteCon/assets/IntroductionFerrite.pdf) from the _Ferrite.jl User & Developer Conference_ that we organized in September of 2022 (see [the program](https://ferrite-fem.github.io/FerriteCon/#program) for other interesting presentations).

[The documentation](https://ferrite-fem.github.io/Ferrite.jl/) 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](https://github.com/Ferrite-FEM/Ferrite.jl/blob/master/CHANGELOG.md)\* 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!

---

<div class="post-metadata">

### Author: ![fredrikekre](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/fredrikekre/32/1688_2.png) [@fredrikekre](https://discourse.julialang.org/u/fredrikekre)
#### Post date: [February 28, 2023, 2:59pm UTC](https://discourse.julialang.org/t/ferrite-jl-release-announcements/93157/2 "2023-02-28T14:59:24Z")

</div>

### Ferrite version 0.3.12

New release, with various bugfixes, see [CHANGELOG.md](https://github.com/Ferrite-FEM/Ferrite.jl/blob/master/CHANGELOG.md#0312---2023-02-28) for details.

---

<div class="post-metadata">

### Author: ![em-phy](https://avatars.discourse-cdn.com/v4/letter/e/6bbea6/32.png) [@em-phy](https://discourse.julialang.org/u/em-phy)
#### Post date: [March 3, 2023, 1:48pm UTC](https://discourse.julialang.org/t/ferrite-jl-release-announcements/93157/3 "2023-03-03T13:48:42Z")

</div>

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

---

<div class="post-metadata">

### Author: ![fredrikekre](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/fredrikekre/32/1688_2.png) [@fredrikekre](https://discourse.julialang.org/u/fredrikekre)
#### Post date: [March 3, 2023, 3:58pm UTC](https://discourse.julialang.org/t/ferrite-jl-release-announcements/93157/4 "2023-03-03T15:58:48Z")

</div>

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):

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

```

---

<div class="post-metadata">

### Author: ![em-phy](https://avatars.discourse-cdn.com/v4/letter/e/6bbea6/32.png) [@em-phy](https://discourse.julialang.org/u/em-phy)
#### Post date: [March 3, 2023, 4:52pm UTC](https://discourse.julialang.org/t/ferrite-jl-release-announcements/93157/5 "2023-03-03T16:52:06Z")

</div>

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

---

<div class="post-metadata">

### Author: ![koehlerson](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/koehlerson/32/13108_2.png) [@koehlerson](https://discourse.julialang.org/u/koehlerson)
#### Post date: [March 7, 2023, 10:46pm UTC](https://discourse.julialang.org/t/ferrite-jl-release-announcements/93157/6 "2023-03-07T22:46:31Z")

</div>

In addition to [Ferrite.jl](https://github.com/Ferrite-FEM/Ferrite.jl), my colleague [Dennis Ogiermann](https://github.com/termi-official) and I have been working on [FerriteViz.jl](https://github.com/Ferrite-FEM/FerriteViz.jl). Yesterday, we released the new version 0.2.0 with cool new features. [FerriteViz.jl](https://github.com/Ferrite-FEM/FerriteViz.jl) was born due to the need of visualizing finite element results computed with [Ferrite.jl](https://github.com/Ferrite-FEM/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](https://github.com/Ferrite-FEM/FerriteViz.jl)
- `warp by scalar` filter from paraview =\> `surface` in [FerriteViz.jl](https://github.com/Ferrite-FEM/FerriteViz.jl)
- classic contour plots of FE fields in ParaView =\> `solutionplot` in [FerriteViz.jl](https://github.com/Ferrite-FEM/FerriteViz.jl)
- plot of cell/elementwise constant data =\> `cellplot` in [FerriteViz.jl](https://github.com/Ferrite-FEM/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](https://github.com/Ferrite-FEM/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](https://ferrite-fem.github.io/FerriteViz.jl/stable/tutorial/)!

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

- [we can visualize discontinuous gradient fields without detours](https://ferrite-fem.github.io/FerriteViz.jl/stable/atopics/#Gradient-field-visualization)
- you can [plot synchronously while your simulation runs](https://ferrite-fem.github.io/FerriteViz.jl/stable/atopics/#Live-plotting)
- produce true vector graphics with CairoMakie.jl (be careful though :D)

## 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](https://github.com/Ferrite-FEM/FerriteViz.jl/pull/63)
- 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!

---

<div class="post-metadata">

### Author: ![juliohm](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/juliohm/32/215266_2.png) [@juliohm](https://discourse.julialang.org/u/juliohm)
#### Post date: [March 7, 2023, 11:02pm UTC](https://discourse.julialang.org/t/ferrite-jl-release-announcements/93157/7 "2023-03-07T23:02:38Z")

</div>

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:

> **[GitHub - JuliaGeometry/MeshViz.jl: Makie.jl recipes for visualization of...](https://github.com/JuliaGeometry/MeshViz.jl)**
>
> Makie.jl recipes for visualization of Meshes.jl. Contribute to JuliaGeometry/MeshViz.jl development by creating an account on GitHub.

---

<div class="post-metadata">

### Author: ![ranocha](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ranocha/32/35588_2.png) [@ranocha](https://discourse.julialang.org/u/ranocha)
#### Post date: [March 8, 2023, 6:49am UTC](https://discourse.julialang.org/t/ferrite-jl-release-announcements/93157/8 "2023-03-08T06:49:41Z")

</div>

That sounds intriguing! Do you think there is potential to use this for discontinuous Galerkin methods implemented in [Trixi.jl](https://github.com/trixi-framework/Trixi.jl/) as well?

---

<div class="post-metadata">

### Author: ![koehlerson](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/koehlerson/32/13108_2.png) [@koehlerson](https://discourse.julialang.org/u/koehlerson)
#### Post date: [March 8, 2023, 10:46am UTC](https://discourse.julialang.org/t/ferrite-jl-release-announcements/93157/9 "2023-03-08T10:46:15Z")

</div>

Definitely, since we designed the underlying machinery specifically for discontinuous plotting (which already starts for cell-wise constant data). Dennis did a [PR](https://github.com/Ferrite-FEM/FerriteViz.jl/pull/16) 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](https://user-images.githubusercontent.com/9196588/138382765-e994da57-60f3-49e7-8c33-f1d63b1f0d1d.png) 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](https://github.com/trixi-framework/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](https://github.com/trixi-framework/Trixi.jl/tree/main/src/visualization) What is missing there?

---

<div class="post-metadata">

### Author: ![ranocha](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ranocha/32/35588_2.png) [@ranocha](https://discourse.julialang.org/u/ranocha)
#### Post date: [March 8, 2023, 11:14am UTC](https://discourse.julialang.org/t/ferrite-jl-release-announcements/93157/10 "2023-03-08T11:14:11Z")

</div>

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 🙂

---

<div class="post-metadata">

### Author: ![fredrikekre](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/fredrikekre/32/1688_2.png) [@fredrikekre](https://discourse.julialang.org/u/fredrikekre)
#### Post date: [March 23, 2023, 12:08pm UTC](https://discourse.julialang.org/t/ferrite-jl-release-announcements/93157/11 "2023-03-23T12:08:25Z")

</div>

## 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](https://github.com/Ferrite-FEM/Ferrite.jl/pull/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](https://github.com/Ferrite-FEM/Ferrite.jl/pull/623)).
- New [Developer documentation](https://ferrite-fem.github.io/Ferrite.jl/stable/devdocs/) 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](https://github.com/Ferrite-FEM/Ferrite.jl/blob/master/CHANGELOG.md#0313---2023-03-23) for all changes and more details.

---

<div class="post-metadata">

### Author: ![fredrikekre](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/fredrikekre/32/1688_2.png) [@fredrikekre](https://discourse.julialang.org/u/fredrikekre)
#### Post date: [April 3, 2023, 8:30am UTC](https://discourse.julialang.org/t/ferrite-jl-release-announcements/93157/12 "2023-04-03T08:30:46Z")

</div>

## 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](https://github.com/Ferrite-FEM/Ferrite.jl/blob/master/CHANGELOG.md#0314---2023-04-03) for all changes and more details.

---

<div class="post-metadata">

### Author: ![koehlerson](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/koehlerson/32/13108_2.png) [@koehlerson](https://discourse.julialang.org/u/koehlerson)
#### Post date: [May 24, 2023, 11:07am UTC](https://discourse.julialang.org/t/ferrite-jl-release-announcements/93157/13 "2023-05-24T11:07:44Z")

</div>

## 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](https://github.com/kimauth/FerriteCohesiveZones.jl):  
 ![cohesive zone model](https://global.discourse-cdn.com/julialang/original/3X/0/c/0c055bdbf11cab1b84f798d6b85cf060b33ce925.gif)

See the [CHANGELOG.md](https://github.com/Ferrite-FEM/FerriteViz.jl/blob/c64397c9110d0c669067c322b6a77d87e78017ef/CHANGELOG.md) for all changes and links to PRs with more details.

---

<div class="post-metadata">

### Author: ![termi-official](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/termi-official/32/47815_2.png) [@termi-official](https://discourse.julialang.org/u/termi-official)
#### Post date: [November 14, 2023, 1:10pm UTC](https://discourse.julialang.org/t/ferrite-jl-release-announcements/93157/14 "2023-11-14T13:10:48Z")

</div>

## 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](https://github.com/Ferrite-FEM/FerriteViz.jl/blob/bef6e8f423aca17f281a02d77801bd6965b553bf/CHANGELOG.md) for all changes and links to PRs with more details.

---

<div class="post-metadata">

### Author: ![kings94](https://avatars.discourse-cdn.com/v4/letter/k/c67d28/32.png) [@kings94](https://discourse.julialang.org/u/kings94)
#### Post date: [September 12, 2024, 4:48pm UTC](https://discourse.julialang.org/t/ferrite-jl-release-announcements/93157/15 "2024-09-12T16:48:38Z")

</div>

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?

---

<div class="post-metadata">

### Author: ![fredrikekre](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/fredrikekre/32/1688_2.png) [@fredrikekre](https://discourse.julialang.org/u/fredrikekre)
#### Post date: [September 30, 2024, 3:20pm UTC](https://discourse.julialang.org/t/ferrite-jl-release-announcements/93157/16 "2024-09-30T15:20:27Z")

</div>

# Ferrite version 1.0.0

 ![image](https://global.discourse-cdn.com/julialang/original/3X/3/d/3d0271d250428615b3606c51a75fd81dd82d9d60.jpeg)

_Reactant concentration field from solving the Gray-Scott model with embedded elements on a spherical surface (see [tutorial](https://ferrite-fem.github.io/Ferrite.jl/stable/tutorials/reactive_surface/))_

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

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](https://github.com/Ferrite-FEM/Ferrite.jl/blob/master/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](https://ferrite-fem.github.io/Ferrite.jl/) have been reworked. It is now split into four major parts\[1\]: [Tutorials](https://ferrite-fem.github.io/Ferrite.jl/stable/tutorials/), [Topic guides](https://ferrite-fem.github.io/Ferrite.jl/stable/topics/), [API reference](https://ferrite-fem.github.io/Ferrite.jl/stable/reference/), and [How-to guides](https://ferrite-fem.github.io/Ferrite.jl/stable/howto/). In addition there is also a [Code gallery](https://ferrite-fem.github.io/Ferrite.jl/stable/gallery/) and [Developer documentation](https://ferrite-fem.github.io/Ferrite.jl/stable/devdocs/).
- 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`](https://github.com/AbdAlazezAhmed). See the [tutorial on discontinuous Galerkin heat equation](https://ferrite-fem.github.io/Ferrite.jl/dev/tutorials/dg_heat_equation/) and the [presentation from last years FerriteCon](https://youtu.be/t41UALrzxNg?si=DvtypxgmobTr1FmY) 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`](https://github.com/kimauth) spearheaded this work and also [presented this development during last years FerriteCon](https://youtu.be/r6CVZffKCAg?si=ag3HgjvokFOerFIu).
- 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`](https://github.com/KnutAM)).
- Lots and lots of internal changes (mainly by [`@KnutAM`](https://github.com/KnutAM), [`@termi-official`](https://github.com/termi-official), and [`@lijas`](https://github.com/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](https://github.com/Ferrite-FEM/Ferrite.jl/pull/798)), 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](https://github.com/Ferrite-FEM/Ferrite.jl/pull/1081) for [HYPRE.jl](https://github.com/fredrikekre/HYPRE.jl) support and [this PR](https://github.com/Ferrite-FEM/Ferrite.jl/pull/864) for [SparseMatricesCSR.jl](https://github.com/gridap/SparseMatricesCSR.jl) support.

Thanks to everyone who contributed!

* * *

1. Following the [Diátaxis Framework](https://diataxis.fr/)

---

<div class="post-metadata">

### Author: ![Jake](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jake/32/46007_2.png) [@Jake](https://discourse.julialang.org/u/Jake)
#### Post date: [September 30, 2024, 8:10pm UTC](https://discourse.julialang.org/t/ferrite-jl-release-announcements/93157/17 "2024-09-30T20:10:25Z")

</div>

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

---

<div class="post-metadata">

### Author: ![fredrikekre](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/fredrikekre/32/1688_2.png) [@fredrikekre](https://discourse.julialang.org/u/fredrikekre)
#### Post date: [September 30, 2024, 10:12pm UTC](https://discourse.julialang.org/t/ferrite-jl-release-announcements/93157/18 "2024-09-30T22:12:14Z")

</div>

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

---

<div class="post-metadata">

### Author: ![yolhan\_mannes](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/yolhan_mannes/32/220485_2.png) [@yolhan\_mannes](https://discourse.julialang.org/u/yolhan_mannes)
#### Post date: [October 3, 2024, 11:45am UTC](https://discourse.julialang.org/t/ferrite-jl-release-announcements/93157/19 "2024-10-03T11:45:06Z")

</div>

Really nice release, will try out to implement Local DG method (see [https://www.global-sci.org/v1/cicp/openaccess/v7\_1.pdf](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 !

---

<div class="post-metadata">

### Author: ![fredrikekre](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/fredrikekre/32/1688_2.png) [@fredrikekre](https://discourse.julialang.org/u/fredrikekre)
#### Post date: [May 9, 2025, 7:19am UTC](https://discourse.julialang.org/t/ferrite-jl-release-announcements/93157/20 "2025-05-09T07:19:28Z")

</div>

# Ferrite version 1.1.0

We have recently release Ferrite version 1.1.0, the first feature release in the 1.X release series. In this release we finally take advantage of the large restructuring and breaking changes that was done for the 1.0.0 release to provide new functionality. The full list of changes can be found in [CHANGELOG.md](https://github.com/Ferrite-FEM/Ferrite.jl/blob/master/CHANGELOG.md) but a summary of the main features follows below.

The main feature of this release is the addition of vector interpolations for H(div) and H(curl) spaces. In particular we have added the interpolations `Nedelec`, `RaviartThomas`, and `BrezziDouglasMarini`. In order to apply (non-homogeneous) boundary conditions for these interpolations we have also added a new boundary condition type called `ProjectedDirichlet` which projects the user function on the boundary on the interpolation space. (In theory this type of boundary condition can also be used for regular nodal interpolations (e.g. Lagrange) but this has not yet been implemented.)

Thanks to everyone who contributed!

[Next page](https://discourse.julialang.org/t/ferrite-jl-release-announcements/93157.md?page=2)
