These visualization pipelines are the kind of feature you would get for free if the output of a Ferrite.jl simulation lived on a GeoTables.jl over a Meshes.jl. We support nearly 100 transformations at this point. I understand you might have specific needs that justify spending human resources writing project-specific viz features though.
Not sure why you try to start a discussion in a release announcement thread, but I have to really correct that statement you made that we get the same features for free. We started developing FerriteViz in 2021 as a specialized visualizer for finite elements and we actually tried to get the foundation integrated with GeometryBasics.jl . Meshes.jl has been started in 2024 and I have looked into the package every few months to see where it goes, but there is just not much infrastructure which we can use for our purposes. The library itself is fine, it just does not fit any of our needs. Means, even if we depend on Meshes.jl, which is of course possible, then we still need to roll all the internal infrastructure to handle the mappings and nonlinearities ourselves. Also note that we already rolled the necessary infrastructure and at this point I honestly do not see if there is any gain in refactoring the front-end of our visualizer to fit into different framework just for the purpose of having that other framework as a front-end.
If you want to discuss this with the community, then I would kindly ask to rather open up a separate thread taking up that matter about visualization frameworks, as I do not think that future users/developers/readers/… will search for a discussion about finite element visualization frameworks in the Ferrite release announcement thread.
Sounds good. I wanted to understand the rationale and thought it would be a good idea to comment on this thread. Sorry.
It is not clear to me why Meshes.jl does not fullfill your requirements. I can’t understand how GeometryBasics.jl is preferred in the context of FEM.
Please feel free to ask forum admins to move this discussion to a separate thread. Happy to continue the discussion.
You should understand, if anyone, I bet a lot of people said “just export to VTK and let ParaView handle it” with your project 
It is a reasonable solution if the only objective is to perform the standard set of visualizations. Sometimes, however, people will be interested in filtering, transforming the solution interactively, adding and removing objects from the scene, and that is when Makie.jl recipes come in.
My first comment was about human resources dedicated to a project-specific viewer, which could be saved if all these different projects shared a common Meshes.jl infrastructure 
❯ Do you think Meshes.jl and its visualization would be a good fit for finite element simulation visualization?
● Short answer: no — not as a foundation for FE visualization, though it’s a reasonable interop/geometry library to sit next to one.
Having just looked at where FerriteViz has landed (a FEData dataset + composable filter pipeline: WarpByVector, CrinkleClip, Threshold, Gradient, Refine, AddQuadraturePointData), you’ve essentially adopted the VTK/ParaView data-model. That’s the right abstraction for FE, and it’s a different abstraction than Meshes.jl offers.
Where the mismatch bites:
- No function-space concept. Meshes.jl elements are straight-sided geometric primitives defined by vertices; a SimpleMesh + GeoTable carries data on vertices or on elements, full stop. FE fields are DoF-based: quadratic/serendipity geometry, discontinuous (per-cell-per-node) fields, H(div)/H(curl) interpolations, quadrature-point data. Every one of those has to be tessellated down to linear triangles anyway — which is exactly what tessellation.jl/qptessellation.jl do, straight from Ferrite’s interpolations. Routing through Meshes.jl means losing the interpolation information first and then trying to recover fidelity by refinement.
- viz is a thin Makie recipe. It buys you nothing FerriteViz doesn’t already have via direct
Makie.mesh/ShaderAbstractions access — and it costs you control over shading, per-vertex color observables, and the SpecApi-driven interactive viewer. FE viz needs the low-level path.- Points carry units + CRS. Since the CoordRefSystems.jl integration, Meshes.Point is a georeferenced, unitful thing. That’s excellent for GeoStats and a tax for FE, where you want plain Vec{dim,T}/Tensors coordinates that convert to Point3f with zero ceremony.
- Release cadence. Meshes.jl is the substrate of a fast-moving ecosystem and breaks regularly. FerriteViz’s compat surface is already tight (Ferrite 1, Makie 0.24, GeometryBasics 0.5) — adding a heavy dep whose breaking releases you don’t control makes every Ferrite/Makie bump harder.
Where it would genuinely fit: as an optional extension for geometry operations FerriteViz doesn’t want to own — clipping/boolean ops against arbitrary solids, point-in-cell queries, isosurface/contour extraction, sampling, partitioning. A MeshesExt that converts a tessellated FEData → SimpleMesh for those operations (and back) is cheap and low-risk. That’s interop, not architecture.
If you’re looking for something to lean on more heavily, the more natural candidates are staying with GeometryBasics + Makie directly (status quo, and it’s working), or leaning further into the VTK data-model you’ve already replicated.
Below you can find some replies. Is this coming from an AI agent? Keep in mind that AI agents use your chat history to give very biased answers. If I ask the same question to my ChatGPT, it will say wonders about Meshes.jl and how it should be used instead of reinventing the wheel.
That is by design, like with GeometryBasics.jl. Any function approximation is in the FE scope, not the geometry library. Given well-designed primitives, it shouldn’t be hard to write higher-level constructs, and that is probably what you did in Ferrite.jl on top of GeometryBasics.jl anyways.
It buys you development time. Our recipe works with all kinds of meshes and GIS stuff, with actual coordinates in the real world, and that is very hard to reproduce. If you intend to do FE with models that are actually located in the globe, you will better understand the challenges involved.
I am genuinely curious about this one. Why is it an issue to assume that “meter” units are everywhere? At the end of the day, you are dealing with units implicitly when you use raw numbers. Is it about runtime performance? Type inference?
Depending on your perspective, that could be seen as a good thing. It is actively maintained with issues fixed within 24h on average I would say. We break sometimes because developing a general geometry library is not a trivial thing. We are almost there, but it took a lot of iteration to achieve a design that can encompass non-Euclidean geometry, CRS, etc.
100%. So were the other posts. Ps @koehlerson this is against the guidelines, see Guidelines - Julia Programming Language
Don’t post generative AI outputs (but direct human language translation and minor editing is ok).
100%. So were the other posts.
What do you mean? The version announcement post?
Ps @koehlerson this is against the guidelines, see Guidelines - Julia Programming Language
Didn’t know, but to be fair it’s not like I stated it as my own personal statement. It’s in a quote block.
Thanks for the detailed reply. I’d actually be quite curious to see what your AI agent makes of the very same prompt.
One thing that might help: the announcement post is about FerriteViz.jl rather than Ferrite.jl itself. FerriteViz.jl is only a thin layer between Ferrite.jl and Makie.jl, and I think re-reading it with that in mind clears up a few of the points below.
That is by design, like with GeometryBasics.jl. Any function approximation is in the FE scope, not the geometry library. Given well-designed primitives, it shouldn’t be hard to write higher-level constructs, and that is probably what you did in Ferrite.jl on top of GeometryBasics.jl anyways.
I think there may be a misunderstanding about the current pipeline here: Ferrite.jl (with its own mesh data structure) → FerriteViz.jl → Makie.jl. From where I stand, an additional intermediate layer wouldn’t buy us much. It would cost time and reduce flexibility for the more advanced, FE-specific things we want to visualize. For what it’s worth, Ferrite.jl doesn’t depend on GeometryBasics.jl at all.
It buys you development time. Our recipe works with all kinds of meshes and GIS stuff, with actual coordinates in the real world, and that is very hard to reproduce. If you intend to do FE with models that are actually located in the globe, you will better understand the challenges involved.
I can see the appeal, and I don’t doubt that the GIS side is hard to reproduce. In our case, though, it would mean tying ourselves to an API that (at least from my perspective) doesn’t quite fit the use case.
I am genuinely curious about this one. Why is it an issue to assume that “meter” units are everywhere? At the end of the day, you are dealing with units implicitly when you use raw numbers. Is it about runtime performance? Type inference?
I can only speak for FerriteViz.jl here, but carrying units around doesn’t gain us anything in that context, so it’s hard to justify the extra baggage.
None of this is meant to dismiss your approach, if you feel GeoTables.jl and Meshes.jl would be a good fit for a visualization library on top of Ferrite.jl, please do go for it. I’d be genuinely interested to see how it turns out.
I don’t think that matters, it’s still AI output. There is so much AI output already everywhere, just makes me sad that it’s also dumped into discussions between humans. That’s all
I used the exact same query as you: ChatGPT - Meshes.jl FEM Visualization
Notice that the missing ingredients could be simple feature requests in Meshes.jl.
Indeed, I misunderstood the relation between the packages. It is Ferrite.jl that is using a dedicated set of mesh types, which is forcing you to redo the viz work we did in Meshes.jl + Makie.jl. So FerriteViz.jl should be compared to our MeshesMakieExt.jl extension.
It is fine to decide not to use another package as a dependency. You just need to bear in mind the burden of maintaining a project-specific viz library. It takes a lot of time and energy, and I try to always find common ground with other developers writing simulation packages. Some people already rely on Meshes.jl for their FEM, FVM, FDM, … work, and they enjoy it as far as I can tell.
If the integration is not tight with the Ferrite.jl internals, there is no much gain here. We can always communicate through IO where you save your simulation results on disk and we load it with GeoIO.jl to use the Meshes.jl + GeoTables.jl features. GeoIO.jl supports tons of formats natively already (which is another benefit of porting stuff to Meshes.jl).
That is by design, like with GeometryBasics.jl. Any function approximation is in the FE scope, not the geometry library. Given well-designed primitives, it shouldn’t be hard to write higher-level constructs, and that is probably what you did in Ferrite.jl on top of GeometryBasics.jl anyways.
As Maxi already clarified before, Ferrite.jl does not use GeometryBasics.jl . We use GeometryBasics.jl in FerriteViz.jl to wire the only the necessary data as close as possible to the Makie shaders. We are also still aiming to provide custom shader components for performance reasons. This goal was one of the original motivations – we are just not there yet.
It buys you development time. Our recipe works with all kinds of meshes […]
That is again the same claim and I still think this is not correct. The only tools I know so far which can handle FE visualization (of nonlinearities) on high order meshes faithfully are visit and glvis. Hacking this into ParaView exports is already quite an uphill battle. I also have not even seen Meshes.jl providing infrastructure for Lagrangian geometries – and I am also not asking to do so. Also note that there is not much overlap between what Meshes.jl provides and what FerriteViz.jl provides. And let me repeat that: This is fine. When it comes to mesh representations there is simply no one-size-fits-it-all solution.
Depending on your perspective, that could be seen as a good thing. […] We break sometimes because developing a general geometry library is not a trivial thing. […]
While I agree that breaking stuff can be a good thing – this is simply a part of the software life cycle – there is something you forget here. FerriteViz is a side-project of two people using it in teaching finite elements. We already had to spend considerable capacity in upgrading the Makie version. More dependencies with more frequent breaking changes then just slows things down further and can you force users to block package updates transiently. This is does not save us development time in the end, if the added dependency does not bring significant value.
I don’t think that matters, it’s still AI output. There is so much AI output already everywhere, just makes me sad that it’s also dumped into discussions between humans. That’s all
I hope that you can see that it is really tiresome for us all to justify the usage of a screwdriver for a screw, and repeating over and over and over again why a hammer is just not the right tool here. The AI faithfully summarized what we already said in the past, e.g. in issues and on slack.
Some people already rely on Meshes.jl for their FEM, FVM, […]
Now I am curious. Taking another look at some of the large FEM and FVM packages Gridap (GitHub - gridap/GridapMakie.jl: Makie plotting recipes for Gridap · GitHub), Trixi (Trixi.jl/docs/src/visualization.md at main · trixi-framework/Trixi.jl · GitHub), JuliaFEM, VoronoiFEM (GitHub - WIAS-PDELib/GridVisualize.jl · GitHub), (GitHub - SciML/FiniteVolumeMethod.jl: Solver for two-dimensional conservation equations using the finite volume method in Julia. · GitHub), Oceananigans (Baroclinic adjustment | Oceananigans.jl) I could not find a single large framework using Meshes.jl for their grid representation in neither the simulation nor the visualization. Can you share some examples of frameworks using Meshes.jl ? I am especially interested in how they use Meshes.jl to deal with the nonlinearities and the mappings.
That would go away for example, and this burden would be on us maintaining Meshes.jl + Makie.jl integration. Can you see that?
We don’t keep a list, and many are probably not even registered as they are single-person projects. If you feel that Meshes.jl is not useful for Ferrite.jl, that is completely understandable.
In my personal experience, this issue is more about lack of communication and/or effort to reuse other software stacks than actual technical constraints. We would be happy to add features to meet FEM needs, and share the burden of maintaining these features as opposed to asking you two to write more viz code in the future.
Looking forward to seeing where the project goes.
Best,