Living Perl: From Scripting to Geodynamics

A Different Path into Scientific Computing.

Because when you’re working on complex physical problems — not just scripts, not just data analysis, but things like Stokes’ flow, heat transfer, nonlinear rheology — you don’t want the language to be another hurdle. You want the language to disappear. You want it to become a tool you can think with.

For me, that language was always Perl. So, at some point, I had to face a somewhat uncomfortable question:

Do I really need to switch languages to do serious scientific computing?

Or, more importantly:

Is the limitation the language, or is it the way we use it?

After a while, that question stopped being theoretical and became practical. I was getting more involved in geodynamics, especially in problems related to subduction zones: viscous flow in the mantle, temperature evolution, nonlinear viscosity, and very long time scales. These are not small problems, and they are usually solved using large, well-established frameworks.

So I had two options.

• I could fully adapt to the existing ecosystem and change the way I worked, thought, and built tools.
• Or I could take a more uncertain path: keep my way of working, keep my main language, and try to build the tools I needed from the ground up.

I chose the second option.

Certainly not the most conventional one. But it was the one that made sense to me.

That was the moment when what later became APEXS-FEM started to take shape: not as a big, ambitious project at the beginning, but as a simple idea — I wanted to solve real geodynamics problems using Perl as the main language, and building the numerical machinery I needed step by step.

I started it because I wanted to solve geodynamics problems, and I wanted to do it in a language I could think in.

The Tools I Started With

Before things became difficult — and they did — I was not starting from zero. I was bringing with me a set of tools and ways of working that had been evolving for years.

Perl, for me, was never just a scripting language. It was an environment where I could move fast, manipulate data, automate workflows, and connect different parts of a computational pipeline without friction.

Some pieces were especially important: • PDL (Perl Data Language), which gave me vectorized operations and numerical capabilities comparable to what many associate with other scientific ecosystems. • XS, which allowed me to go lower level when needed, without abandoning Perl as the main interface. • Gmsh, for mesh generation — an essential component for any finite element workflow. • Interfaces to external libraries like PETSc, which would later become critical for solving large linear systems. • And ParaView, which made it possible to actually see what was happening.

At that stage, everything felt… manageable. I could assemble small pieces, test ideas, build prototypes, and see results relatively quickly. The flexibility of Perl made it easy to experiment and to keep full control over what was happening under the hood.

But there was something I hadn’t fully faced yet. Up to that point, I wasn’t really solving the full problem.

I was preparing for it.

The Wall

And then I hit the wall. It didn’t happen all at once. It came in layers.

The first issue was performance. Assembling matrices element by element in a scripting language is not fast. At small scales, it works. But at realistic scales, it becomes a bottleneck. At some point, I was spending more time assembling the system than actually solving it. That was the first signal that something had to change.

Then came memory.

A 2D Stokes system with thousands of elements quickly turns into large sparse matrices. Managing them efficiently is not optional — it’s the difference between a simulation that runs and one that crashes. That forced me to rethink how data was stored and handled. It wasn’t just about computing anymore. It was about structure.

Then came the solver.

At that scale, you don’t “just solve” a system. You need robust, scalable methods. Iterative solvers, preconditioners, flexibility. That’s when external tools became necessary, and integrating them without breaking the workflow became its own challenge.

And then came the real problem: Nonlinearity.

Viscosity was no longer a constant. It depended on the solution itself — on velocity, on temperature. That creates a circular problem: you need the solution to compute the coefficients, but you need the coefficients to compute the solution.

That’s when things stopped being simple. Iterations, convergence criteria, and stability became essential. There could be cases where things diverged without us realizing it, or converged to something that didn’t make sense from a physical standpoint.

At that moment, it became clear: it was no longer just about writing code. It was about solving a physical problem through code, and making sure that every step of that process made sense.

The First Time It Looked Real

At some point, things started to look… real. Not perfect. Not fully validated. But no longer random numbers.

When I visualized the temperature field in ParaView, I could see the structure of a subduction system emerging: the cold slab descending into the mantle, the thermal gradients in the wedge, the curvature of the isotherms. That was the first moment when the model stopped being just code.

It started to look like geology.

Temperature field computed with APEXS-FEM for a subduction setup. The model begins to reproduce the expected thermal structure of the mantle wedge

Of course, seeing something that “looks right” is not enough. So the next step was to compare it against a known reference.

One of the classical benchmarks in subduction zone modeling is the work by Van Keken et al. (2008), which provides temperature predictions for different rheological cases.

Reference temperature field from Van Keken et al. (2008), case Aa

Crossing The Wall

In the end, the wall was not a single obstacle.

It was performance. It was memory. It was sparse matrices. It was external solvers. It was nonlinear rheology. It was convergence.

Each problem forced the code to evolve.

What started as a simple scripting project slowly became something else: a hybrid system, with Perl orchestrating, C handling the heavy computations, and external libraries solving large linear systems. Visualization in ParaView turned numbers into something I could actually understand.

Somewhere along the way, without really noticing, the project stopped being “a Perl script”. It became a modeling tool.

A tool that could simulate subduction, temperature, viscosity, and flow in the mantle wedge. A tool that could be compared against published benchmarks. A tool that could be used to explore geodynamic problems. And that’s when I realized something important.

The biggest limitation was never the programming language. The real limitation was understanding the physics, the numerical methods, and how all the pieces fit together.

Perl was never the wall. The wall was everything else. And once you cross that wall, the language becomes just another tool.

Architecture — Holding the Hat by the Brim

One of the key decisions in this project was not to write everything from scratch, but to connect the right tools and make them work together.

The architecture slowly evolved into something like this:

• Geometry and mesh generation with Gmsh
• Heavy numerical integration and element assembly in C through XS
• Vector and matrix handling with PDL
• Sparse matrix storage in CSR format
• Linear system solution using PETSc
• Visualization and analysis in ParaView

Perl sits in the middle of everything, orchestrating the workflow: reading the mesh, assembling the system, calling the solver, exporting results, and preparing the data for visualization.

In that sense, Perl is not the heavy lifter. Perl is the conductor, and that changed the way I thought about scientific software.

Instead of writing one monolithic program, the project became a system where each part does one thing well, and Perl connects them into a complete modeling tool. That was, in many ways, the moment of “holding the hat by the brim” — taking control over the whole process, from geometry to visualization.

After all the debugging, the slow assemblies, the solver issues, the nonlinear iterations, and the many times where the results made no sense, I started to understand something that I hadn’t fully realized at the beginning.

Scientific computing is not mainly about programming languages, or frameworks, or which tool is more modern or more popular. It is about building a chain that goes from physics to mathematics, from mathematics to numerical methods, from numerical methods to code, and from code back to something we can interpret as reality.

In scientific computing, the hardest part is not writing code.

It’s building something that actually represents reality.