This story is unavailable.

Interesting writeup. Is there a reason you didn’t at least use IterativeSolvers.jl or an algebraic multigrid for Julia? Sure it’s not \ , but these iterative solvers are in the package ecosystem and let you implement these things with just 1–2 lines of code. If you’re going to let Fortran use a multigrid method, it’s only fair to use an easily available one in Julia (Julia is the only language in this test with a package manager, so that’s one huge difference!)

While that change itself would put it on par with Fortran with far less code, there are other things to notice. For one thing, in Julia there is no reason to actually build the grid. The grid should be instead done with lazy types like linspace (i.e. a type with a few numeric values where [] is actually a function and there’s no array). I haven’t gotten around to making Grids.jl yet but there’s an outline for how to do it and what that gives you: . While this is mostly a trick for rectangular grids, one interesting question is how to generalize this to other “standard” grids.

There are a lot of other improvements that can be done as well. I see from the code that a lot MATLAB-like coding took place. That actually what I did for a lot of my early Julia work, though there’s much better coding styles you can do which involve good use of types. There’s a whole rabbit hole of Julia to jump into to improve this code more.

You sound like you’re interested in continuing to build FEM solvers in Julia. I am a developer for JuliaDiffEq, mostly for DifferentialEquations.jl, and would love to have a chat with you if you’re like to add to the FEM tools available in Julia (I have added some, but have spent more time in developing ODE/SDE solvers with only rudimentary FEM solvers). Stop by the JuliaDiffEq chatroom if you’re interested:

Hope to see more of your Julia work in the future.

Like what you read? Give Chris Rackauckas a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.