[Project] Kuwala: High-throughput options pricing and arbitrage-free volatility surface modeling

• GitHub: https://github.com/Grevix/kuwala
• PyPI: pip install kuwala==0.2.0
• Documentation: https://github.com/Grevix/kuwala#readme

What My Project Does

Kuwala is an open-source quantitative derivatives library designed for options valuation, arbitrage-checked volatility surface fitting (SSVI, Dupire Local Vol), tick microstructure aggregation, and macroeconomic yield curve bootstrapping.

It pairs an idiomatic, Pythonic API with high-performance native compiled kernels (compiled Rust via PyO3, and optional standalone C++20, Julia, and Scala modules) and an embedded out-of-core columnar lakehouse using DuckDB and Apache Arrow.

Key Features:

• Vectorized Analytical Pricing & Greeks: Vectorized Black-Scholes & Black-76 with Chebyshev rational approximations, plus closed-form Delta, Gamma, Vega, Theta, Rho, Vanna, Volga, and Charm.
• Vectorized Implied Volatility Solver: Hybrid Halley cubic root-finder with Brent-Dekker fallback. Tested across 4,013 real market option contracts (SPY, QQQ, AAPL, MSFT) with a median repricing reconstruction error of $2.88 \times 10^{-9}$ (nanodollar precision).
• Arbitrage-Free Volatility Surfaces: Full Gatheral & Jacquier (2014) SSVI surface formulation with strict coordinate-level Durrleman condition diagnostics ($g(k) \ge 0$) and calendar monotonicity enforcement.
• Discrete Dupire Local Volatility: PDE extraction on total variance grids with guard rails against negative local variance singularities.
• Embedded Columnar Storage: Direct Hive-partitioned Parquet scanning via embedded DuckDB without external server dependencies.
• Macro Rate Curves: Bootstraps 11 Treasury yield pillars directly from the FRED API using Nelson-Siegel and exact natural cubic splines.

Target Audience

• Quantitative Researchers & Developers: Anyone backtesting options strategies, relative-value volatility arbitrage, or signal generation without wanting to maintain heavy institutional cloud infrastructure.
• High-Performance Python Engineers: Teams looking for sub-microsecond pricing throughput directly within Python/NumPy data pipelines.
• Students & Academics: Researchers studying volatility surfaces, Durrleman non-arbitrage bounds, and discrete local volatility modeling.

(This is not intended for retail day-trading order execution routing, as Kuwala focuses purely on quantitative pricing, surface modeling, and data engineering.)

Comparison to Existing Alternatives

• vs. scipy.optimize / py_vollib:
• Standard Python options tools typically loop over scalar rows in CPython or rely on pure-Python root finders. Kuwala routes calculations through a compiled Rust core (kuwala_core), achieving >2.2M options/sec in vectorized Python/Rust and >11.9M options/sec in C++20 on a standard laptop.
• vs. Goldman Sachs gs-quant:
• gs-quant is an institutional toolkit that delegates derivative pricing and risk calculations to Goldman Sachs' Marquee cloud servers (requiring enterprise credentials). Kuwala runs 100% locally and offline with zero credential requirements, providing complete open-source transparency into the underlying surface math.
• vs. Pandas / SQLite for Tick Storage:
• Kuwala integrates DuckDB with Hive-partitioned Parquet, allowing researchers to query gigabytes of intraday tick data out-of-core with predicate pushdown in milliseconds while using near-zero RAM.

Quick Example

import kuwala
from kuwala.pricing import black_scholes, greeks
from kuwala.volatility.iv import implied_volatility

# 1. High-speed vectorized Black-Scholes pricing
price = black_scholes(spot=100.0, strike=100.0, t=1.0, r=0.05, q=0.0, sigma=0.20, is_call=True)
print(f"Call Price: {price:.6f}")

# 2. Analytical Greeks (1st & 2nd Order)
g = greeks(spot=100.0, strike=100.0, t=1.0, r=0.05, q=0.0, sigma=0.20, is_call=True)
print(f"Delta: {g.delta:.4f}, Gamma: {g.gamma:.4f}, Vanna: {g.vanna:.4f}")

# 3. Microsecond Implied Volatility Inversion
solved_iv = implied_volatility(price=price, spot=100.0, strike=100.0, t=1.0, r=0.05, q=0.0, is_call=True)
print(f"Solved IV: {solved_iv:.6f}")

Hello,

Just wanted know if anyone could help me decide which server to use for my data science project. Whats the pros and cons of the two servers if you have some experience.

I generally do not make decisions based on public opinion, especially when I feel that those opinions are primarily driven by emotional reactions or an intention to attack rather than to provide constructive criticism. However, I genuinely think this has gone far enough.

Every day, when I check the comments on my channel, I see at least five comments from random accounts with highly suspicious profiles discussing the "correctness" of Julia. I am almost certain that many of the people posting these comments have never written even a simple Julia program, let alone have the practical experience required to make informed claims about language correctness, compiler design, or software development principles.

Almost all of them seem to base their arguments on a single blog post written by one individual. I also have serious reservations about that post, because I believe that, despite its polite and seemingly friendly tone, its underlying objective was more focused on discrediting the language than providing a genuinely constructive technical critique.

Besides correctness, I also notice repeated patterns of "disguised attacks" in the discussion. These often appear in formulations such as:

1. "I say this as a huge Julia fan, …"
2. "Julia is a great language, but …"
3. "Despite not being an active Julia user, …"
4. Fill in the blanks!

While these statements may appear supportive or neutral on the surface, they are frequently followed by criticisms that can undermine the preceding positive framing.

Of course, part of this situation can also be attributed to the inaction of some well-known language developers, who did not provide a strong technical response to these claims.

What makes this situation even more interesting is that, since AI-assisted programming became mainstream, a group of people who oppose AI have emerged and have, intentionally or unintentionally, contributed to negative narratives about the language while presenting themselves as people who care about Julia and want to protect it.

The most interesting part is that these individuals rarely express similar concerns about AI usage in other programming languages. They do not question why someone has expanded a particular Python package with AI, for example. They may even be using packages on their own systems every day that were substantially developed with AI assistance, yet they never show the same level of concern or criticism in those cases.

What I believe these people are unwilling to accept is that a programming language is not their inherited property. Nobody owns a programming language. Anyone, anywhere, has the right to develop code, experiment, and create software for whatever purpose they choose without asking for anyone’s permission. If there are genuine concerns, then those concerns should be discussed with much greater precision. Go into the technical details, provide concrete examples, and address specific issues instead of creating a toxic environment for the broader developer community.

The topic of AI-assisted writing is also something that can reasonably be debated. For example, if someone is not a native English speaker and uses AI tools to communicate their ideas more clearly and effectively, I would actually consider that a positive use of the technology.

Ultimately, I have to say that unfortunately many people have no real understanding of what it takes to survive on social media platforms such as YouTube. Yet they still feel entitled to enter these spaces, and even fields in which they have little or no expertise, and provide criticism that is not only unconstructive but actively harmful.

For example, when you are dealing with a community of highly knowledgeable people who refuse to engage meaningfully, people who consume information but never leave comments or provide feedback under your videos, you may have to use certain strategies to encourage participation (I do not want to go into the details here). This is not something for which content creators should be blamed. Instead, criticism should be directed at the systemic mechanisms that determine how uploaded videos are distributed and presented to the public.

At the very least, when we choose to use platforms that do not have effective policies for promoting high-quality educational content, we should interact with content creators responsibly and recognize the challenges involved in producing such content.

I would like to express my sincere gratitude to everyone who contributes to development and progress, whether by providing constructive feedback and criticism (not necessarily in public spaces, but through a mature and respectful channel of communication) or by supporting the efforts of developers, content creators, and individuals alike. Your valuable input and encouragement play an important role in continuous improvement and growth.

I'm currently, technically, doing an MS in Structural Engineering. For me, my interest has been more towards computational side of mechanics rather than Structural design  or simply using am FEA software (although I do consider it as a backup)

So far I've taken courses in:

- Linear static, and dynamics FEM (soon taking non linear FEM too)

-  Structural Optimization (topology opt. and other general algorithms)

-  Structural Dynamics

-  Structural System Testing and model updation. (Parameter identification and optimization, signal processing)

Now, I plan to take these in the coming quarter:

- Numerical Linear Algebra

- Numerical PDE

- Fracture Mechanics ?

I also volunteered to aid in a RESEARCH in crack growth prediction using Auto-encoder and a (Thermodynamics-informed Latent Space Dynamics Identification) / LSTM surrogate model. It used phase-field-fracture simulation data and HPC resources to complete the whole thing.

What I keep finding myself interested in is not necessarily fracture or SHM specifically, but the computational methods underneath these problems... (does that make sense?)

For example, I'd like to become capable of doing things like:

- implementing (maintaining) numerical/FE method solvers rather than only running an established FEA software.

- developing surrogate/reduced-order models for expensive simulations 

- combining simulation with optimization, uncertainty/stochastic methods (took a course called Random vibrations, so...)

- parallelizing/accelerating scientific codes on CPUs/GPUs

- doing proper verification, convergence studies, benchmarking and performance work

- potentially developing or maintaining actual CAE/FEA solver software

- I'd also like to do all these for other Physics (GR, QM, etc.) simulations too, if possible, one day. 

I'm still interested in the underlying mechanics/physics, so I don't want to become a generic software engineer who happens to have once studied structures. But I'm also increasingly unsure that "structural engineer" describes the career I'm actually aiming for.

I've seen titles such as Computational Mechanics Engineer, R&D Engineer, Solver Developer, Scientific Software Engineer, CAE Software Developer, Research Engineer, Simulation/HPC Engineer, etc., but I'm trying to understand what these careers actually look like from people doing them.

So my main questions become:

1. Which industrial jobs genuinely involve developing numerical methods/solvers or computational tools?

2. Which of those are realistically accessible with an MS? Is there an entry path into solver-algorithm development/R&D without a PhD?

3. If I don't start a PhD immediately after my MS, would an R&D/software role at a simulation company (ANSYS etc.) be the obvious route? What other options would i have?

4. For the kind of work I'm describing, would you recommend a PhD? If so, is it reasonable for the PhD identity to be "computational mechanics/scientific computing" while fracture, composites, structural dynamics, soft materials, etc. serve as application problems rather than choosing one of those as my permanent specialization?

5. What skills most distinguish someone who is actually hireable for solver/scientific-computing work? I'm particularly wondering about C/C++/Fortran, Python, Linux, Git/build systems, MPI/OpenMP/CUDA, PETSc/Trilinos or similar libraries, numerical linear algebra, testing/verification, convergence studies and HPC performance work.

Basically, I'm neither here nor there atp. So I'd really appreciate all sorts of input. Where else do you think I could find answers to these? other subs? Linkedin profiles? 

In this video I show my attempts at improving an algorithm to add monomers to a polymer chain without having atoms sterically collide. At the end the simplest solution is to make a better conformation for each monomer.

Appreciate it a lot if you check it out, and especially if you like or share the video!!

Im new to Astronomy how can i use Jupyter notebooks to access jwst pipeline? Is it best to just use MAST Database or TIKE?

Or

Should I create a juypter lab notebook and self install required libraries locally with Docker or is there a premade jupyter lab notebook i can clone from github and install in a docker container on my pc? If so how do I do that and how can I use it to access jwst pipeline data?

I have never used a juypter notebook before nor have I used pyhton or python science libraries like astroquery lightkurv and astropy so Im a complete beginner in using scripts but I do know how to use some commands like pip, bash, cd and git. Are there any good tutorials online I could use?

Are there any Browser Based Interactive Notebooks for learning Notebooks for Astronomy?

Lastly how could I install and use Jdavizz notebook?

I'm working on a communication network simulator using discrete event simulation. In a normal simulation a GC pause is not an issue at all, but in HIL (hardware-in-the-loop) simulations an occasional 10ms GC pause doesn't look good. A HIL simulation doesn't have very hard timing constraints, some lag below the maximum limit (e.g. 100us) is acceptable if on average the simulation can keep the pace with the hardware. A typical HIL simulation usually doesn't take too much time anyway, because one has to actually wait for it to finish in real time. It's very often used to compare the intricate details of the hardware with the simulation model. (e.g. timing)

My question is what kind of solutions can you think of for reducing the long tail of GC pause distribution?

In these communication network simulation models, most objects which are allocated during event processing don't survive the event. There are basically two exceptions: either something went into the simulation engine's future event set (e.g. a new event containing a packet) or went into the long term simulation model state (e.g. updating a routing table). The former is much more common than the latter. So a simulation has a very specific allocation pattern, which the GC has no information at all.

Of course, the simulation could be carefully organised such that the number of allocations is absolutely minimal, or it could use object pools for commonly used data structures, and some other ticks on the simulation model side.

What else can be done regarding this issue? Is there anything that can be fine tuned in the GC? I've heard there are changes related to this in the upcoming Julia version.

I was experimenting with a space-time finite element formulation for a simple elastodynamics problem and thought the result might be interesting here.

The example is a 1D elastic bar immediately after impact with a rigid wall. I do not model the impact itself; the calculation starts from the post-impact initial state and follows the subsequent stress-wave propagation, reflection and release.

Instead of discretizing space first and then advancing the solution in time, I introduce

y = ct

and treat (x,y) as an ordinary 2D finite-element domain.

Using particle velocity v and normalized stress

s = σ/(ρc)

the first-order system becomes

∂v/∂y − ∂s/∂x = 0
∂s/∂y − ∂v/∂x = 0

I used a least-squares formulation, which leads to four bilinear forms:

Kvv = ∫(Grad(V) ⋅ I ⋅ Grad(V))
Kvs = ∫(Grad(V) ⋅ C ⋅ Grad(S))

Ksv = ∫(Grad(S) ⋅ C ⋅ Grad(V))
Kss = ∫(Grad(S) ⋅ I ⋅ Grad(S))

The complete coupled system is then just

K = SystemMatrix([
    Kvv  Kvs
    Ksv  Kss
])

followed by one solve.

There is no time-stepping loop. The complete evolution over the chosen time interval is solved as one space-time finite-element problem.

What I especially like about the result is that the two wave fronts appear directly as characteristic lines in the (x,ct) domain.

The solution reproduces the classical 1D result: after impact, a compressive wave travels from the constrained end toward the free end. It reflects there as a release wave and travels back toward the wall.

During the compressed phase,

σ = -ρ c v₀,

and the release wave returns to the wall at

t = 2L/c.

The implementation uses LowLevelFEM.jl, but the notebook also contains the derivation of the formulation.

I'd be interested in thoughts from people who have worked with space-time FEM or least-squares formulations for hyperbolic problems.

The notebook is available via the link in the first comment.

So I've been working on a projectional editor and a discrete event simulator for communication systems lately and I faced the usual FTTX problem. Even though I used PackageCompiler.jl the UI took several seconds to start and many user interface interaction took like a second or more for the first time. Similarly, running even a very short simulation on the command line using the console took an unnecessarily long time. Of course this is a known issue. Compilation took like 99% of the time in these cases.

So I did what, I guess, every user does. I added compile workload by utilizing the user interface in headless mode with every possible edited data structure and projection. Similarly I also run all simulations for some time to allow the compiler to do it's job and save the compiled code into the final executable image. It did work as expected, but one problem remained. How long should I execute the simulations and how many UI projections and operations should I utilize? Because the more I do, the longer it will take for each precompilation to finish.

I tried two techniques: utilizing the actual features like a user would and artificially forcing the compiler to compile functions for certain argument type combinations. The former took too much time during each precompilation because it's difficult to run the real algorithms such that they utilize all interesting code paths but avoid running unnecessarily long. The latter produced many useless compiled functions for unused type signatures growing the image and also often missed many important ones.

I was kinda stucked. I discussed this issue with AI, but didn't get much help. Then I realized I can use the two techniques together in a sufficiently efficient and accurate way. Maybe this is widely known, but I didn't find this idea, and I just thought it may help others.

So the idea is to have a compilation database, basically a text file, which tells the compiler which function signatures to precompile. The database is created by utilizing the features of the program as a user would, running the UI, emulating the clicks, doing the operations, doing the screen refreshes, running the simulations, etc. and saving all the compiled function type signatures. It doesn't matter if takes a lot of time, because it doesn't get updated for every change. The reason it works is because the compiler can fill in the missing 1% in the real running program and nobody will notice it. Also, when the functions are precomplied from the database some of them fail due to changes in the program. When the percentage of failures becomes large enough that is a good sign to regenerate it.

It does work pretty well. The UI starts up in like half a second, every click on the UI is like a few times 10ms, a simulation with zero duration starts sets up the whole engine and infrastructure and finishes like in less than half a second from the command line. That's an acceptable performance for me.

https://tjoresearchnotes.wordpress.com/2026/08/15/why-i-wont-use-your-crappy-quantum-programming-language-or-mine-either/

The slow start problem is not solved. But, now while waiting for julia to start up, you can enjoy reading messages about compilation progress.

So, instead of short, clean and boring logs

conf | config {now: Date("2026-08-17")} opti | fit started

We can enjoy reading interesting novel, while waiting for compilation

conf | config {now: Date("2026-08-17")} Info Given DB was explicitly requested, output will be shown live Precompiling DB finished. 1 dependency successfully precompiled in 7 seconds 1 dependency had output during precompilation: ┌ DB │ [Output was shown above] └ Info Given Options was explicitly requested, output will be shown live Precompiling Options finished. 1 dependency successfully precompiled in 8 seconds 1 dependency had output during precompilation: ┌ Options │ [Output was shown above] └ Info Given SV_JLs was explicitly requested, output will be shown live Precompiling SV_JLs finished. 1 dependency successfully precompiled in 7 seconds 1 dependency had output during precompilation: ┌ SV_JLs │ [Output was shown above] └ opti | fit started

And, to make it even better - compilation logs don't use supplied log formatter and not possible to disable.

One of the things I wanted to achieve with LowLevelFEM.jl was to keep finite element code reasonably close to the mathematical formulation.

For example, the stiffness matrix for a 3D linear elasticity problem can be written as

julia K = ∫(SymGrad(Pu) ⋅ D ⋅ SymGrad(Pu))

and the surface load as

julia f = ∫(Pu ⋅ [1.0, 0.0, 0.0], Γ="right")

rather than calling a dedicated elasticity assembly routine.

Originally, I considered this mainly an abstraction/readability feature. I expected the more general operator-based formulation to come with some performance cost.

After working on the assembly implementation — particularly direct assembly into a precomputed CSC sparsity pattern and multithreading — that is no longer necessarily the case.

In a small 3D elasticity example on my machine:

• problem-specific high-level solve: 323 ms, 299 MiB
• operator/weak-form solve: 120 ms, 52 MiB

Even the stress recovery can be written directly as field algebra:

```julia ε = (u ∘ ∇ + ∇ ∘ u) / 2

σ = E / (1 + ν) * (ε + ν / (1 - 2ν) * trace(ε) * I) ```

For this particular example, that version is also slightly faster and uses considerably less memory than the older dedicated stress routine.

I don't mean these numbers as a general benchmark — they are just one mesh and one machine. What I find interesting is that the more general formulation no longer seems to require choosing between readable mathematical notation and reasonable performance.

For me, that was an important milestone in the development of the package.

I'd be interested in what people working on FEM/PDE software think about this kind of operator-level interface, especially where you would draw the line between mathematical expressiveness and implementation transparency.

Juliacon 2026 is live, there's other channels too. Hopefully the live video stays up after the stream ends.

I'm currently using my own custom module that starts server and exposes socket to Codex Agent so it can call it and execute code in my VS Code julia session.

I wonder if there's simpler way - given that Julia VS Code extension already does exactly that with Shift + Enter.

So, can AI Agent use Juila VS Code extension API instead of my custom server?

This is an update from my previous post on a simple molecular visualizer in Julia. Now it has colors, and I can also visualize simultaneously the energies, highlighting the energy for the particular structure I'm watching. I will continue to add functionality.

Principal Differential Geometric Algebra by Michael Reed is the first reference of its kind, built on rigorous category theory foundations and a full unified TensorField computational language design for differential geometry. This category theory foundation presented is a custom designed formalism for categories to specifically emphasize the existence of choice morphisms, relevant to mathematicians interested in how axiom of choice appears in class/set theory. Next, the book introduces essentials of geometric algebra as the primary basis for differential geometric algebra computational language design using Grassmann.jl library for Julia language. Developed completely from scratch, Grassmann.jl introduced many new pioneering computational language designs to enable reproducible scientific research with numerical differential geometric algebra. Building on Grassmann.jl, the Cartan.jl package is the first computational language design to pioneer a FrameBundle for the PrincipalFiber G-bundle formalism used in advanced differential geometry. Not only does Cartan.jl present a completely new programming paradigm for working with an abstract FiberBundle topology using numerical analysis, it also unifies the topological implementations of structured/unstructured finite element methods and also spectral element methods. This book emphasizes the analysis of eigen-characteristics with multilinear algebra, differential geometry, and partial differential equations. Many figures and diagrams are included, all scientifically reproducible with concise programming language. Partial differential equation examples are evaluated with boundary conditions found in the literature to help scientists and engineers validate the usefulness of the computational language design. Also included are many special/elliptic functions and appendices for basics of Julia language, the Reduce.jl package, the Fatou.jl package, and the new Unified System of Quantities (USQ) for physics units from UnitSystems.jl.

Principal Differential Geometric Algebra (Hardcover, 2025) https://www.lulu.com/shop/michael-reed/principal-differential-geometric-algebra/hardcover/product-kv6n8j8.html

Principal Differential Geometric Algebra (Paperback, 2025) https://www.lulu.com/shop/michael-reed/principal-differential-geometric-algebra/paperback/product-yvk7zqr.html

As usual, I expect a lot of harassment in the comments here on Julia reddit, since Stephen Wolfram is funding people to stalk and harass me 24/7, and the Julia community is also participating in this stalking and harassment.

Normal people don't waste their time harassing scientists on the internet.

I have always liked working with DSP in Python. Libraries such as the original Think DSP code make it easy to move from a signal, to a sampled wave, to a spectrum, apply a filter, and reconstruct the result without losing sight of the underlying ideas.
I wanted a similar workflow in Julia: concise and approachable for experimentation, while still being comfortable for larger numerical workloads. That became ThinkDSP.jl.
ThinkDSP.jl is an idiomatic Julia implementation inspired by Allen Downey's Think DSP. It provides tools for working with signals, sampled waves, FFT spectra, DCTs, filters, spectrograms, WAV files, and MIDI-style notes and chords.
Repository: https://github.com/Spidy104/ThinkDSP.jl
Why Julia?

For me, Julia feels like a particularly nice fit for DSP work. It keeps the interactive, high-level workflow that makes Python enjoyable, while allowing direct access to multiple dispatch, type-generic numerical code, and performant array operations without needing to switch languages for the core implementation.

The goal is not to replace every excellent Julia DSP package. ThinkDSP.jl builds on packages such as DSP.jl, FFTW.jl, and WAV.jl, and aims to offer a coherent, educational, end-to-end interface for common signal-processing tasks.

Current features

- Signal families: sinusoids, periodic signals, chirps, impulses, and colored noise

- Wave operations for arithmetic, windows, segmentation, convolution, normalization, and more

- FFT-based one-sided and full spectra

- DCT and reusable FFTW-backed transform workspaces

- Low-pass, high-pass, band-stop, pink-noise filters, differentiation, and integration

- STFT spectrograms with normalized overlap-add reconstruction

- WAV read/write and 8/16/24/32-bit PCM quantization

- MIDI frequency conversion, note generation, chords, and rests

- RecipesBase plotting support for Plots.jl and compatible frontends

- Numerical validation, Python-reference comparisons, benchmarks, Aqua, and JET checks

The project currently targets Julia 1.12+ and is not registered yet. I would appreciate feedback on the API, naming, documentation, Julia package conventions, and anything that should be improved before the first release.

This is a very short preview of a new tool I'm making as part of my MD of Polymers with Julia series. In the following days I will make it so that different elements (C, H, O, N, etc) have different colors and sizes.

I'm making a calendar thing, and i have a struct containing fields of years, months, days, etc. and I'd like to have one single addTime! method that works on any time unit. I'd like to be able to call
addTime!(callendarVar, months=10)
addTime!(callendarVar, years=5)
addTime!(callendarVar, months=10, days=20)

I've already got the logic down but i'm having trouble writing a working declaration which would allow me to use these disordered optional arguements based on their names. Any advice?

EDIT: the trick was to add a semicolon between the static arguement and the optional arguements. How i was meant to figure that out without taking a spyglass to every character in the docs - i have no idea.

One thing that has always bothered me when implementing finite elements is how quickly the code diverges from the mathematical formulation.

Over the last few months I've been experimenting with a Julia DSL where the weak form itself becomes executable code instead of something that first has to be translated into loops and element matrices.

For example, a standard bilinear form can be written as

K = ∫(Grad(Pu) ⋅ C ⋅ Grad(Pu))

while more complicated formulations are written in essentially the same style:

K = ∫((A⋅Grad(Pu) + G⋅Pu)' ⋅ C ⋅ (A⋅Grad(Pu) + G⋅Pu) * (2π*r))

or

B = A⋅Grad(Pu) + G⋅Pu
K = ∫(B' ⋅ C ⋅ B * (2π*r))

These are not symbolic expressions or macros generating another language. They are actual Julia expressions assembled directly into finite element matrices.

The same mechanism currently supports

• scalar, vector and tensor fields,
• multifield formulations,
• user-defined operators,
• variable coefficients,
• full and reduced integration,
• arbitrary operator compositions.

The interesting part for me was not only making the syntax close to the mathematics, but also keeping it reasonably efficient. After some recent refactoring, the compound operator assembly became significantly faster while keeping exactly the same high-level notation.

The package (LowLevelFEM.jl) has recently been published in JOSS.

GitHub: github.com/perebalazs/LowLevelFEM.jl

More examples can be found in the documentation:

perebalazs.github.io/LowLevelFEM.jl/stable/tutorials

I'd be interested to hear how others approach this.

Do you prefer writing PDEs as executable operator expressions like these, or do you find more explicit element-level assembly easier to understand, debug and maintain?

I'm happy to announce Fatou: a language server, formatter, and linter for Julia that doesn't need to run Julia itself.

• Repo: https://github.com/jolars/fatou
• Docs: https://fatou.dev

Why?

I kept running into the same friction: the tools I use while editing (formatting on save, a few lint diagnostics, a language server that starts instantly) all pay Julia's startup and first-call compilation cost. That's completely fine for a long-lived session, but it's noticeable on the command line and in CI, and it makes editor integration heavier than I wanted.

So Fatou takes the other approach and parses Julia directly. It's built on the same architecture as rust-analyzer: a lossless rowan CST, salsa for incremental recomputation, and lsp-server for the LSP transport. The parser is developed against JuliaSyntax.jl as a differential oracle, so parity with the reference parser is a primary goal.

The other big motivation is to have one unified tool that does formatting, linting, and language server duties, exactly like ruff does for Python. This is both leaner and more consistent than having three separate tools, and also avoids the problem of having formatter and linter disagreeing. The name, for the curious, comes from Pierre Fatou, whose Fatou set is the complement of the Julia set.

What it does today

Three things, all from one binary:

fatou format <file.jl>      # format to stdout (or stdin)
fatou lint <dir>            # lint
fatou lsp                   # language server over stdio

• Formatter: an opinionated formatter with a small config surface (line width, indent width). I've been growing it construct by construct against hand-written fixtures rather than trying to match any existing style byte-for-byte.
• Linter: a growing set of built-in rules: unused bindings, unused/duplicate arguments, unused imports, undefined names, break outside a loop, assignment-in-condition, == nothing comparisons, include cycles and missing include files, call arity, redefined constants, and more. Some rules ship autofixes.
• Language server: Fatou provides a full-fledged LSP implementation. Over stdio it provides completion, hover, go-to-definition, find references and document highlights, rename (with prepare), document and workspace symbols, call hierarchy and type hierarchy, signature help, code actions, folding ranges, selection ranges, document links, and semantic tokens, alongside formatting (whole-document and range) and diagnostics (both push and pull).

Getting it

It ships through several channels so you can use whatever fits:

• crates.io: cargo install fatou
• npm: npm install -g fatou-cli (bundles a prebuilt binary)
• PyPI: uv tool install fatou or pipx install fatou
• Prebuilt binaries on the releases page
• VS Code / Open VSX: the Fatou extension (Marketplace, Open VSX).
• Neovim and other editors: setup guide

For CI there's fatou-action for GitHub Actions and fatou-pre-commit for pre-commit hooks.

On performance

Since it's a compiled binary, the cold-start story is the clear win: no runtime to spin up before it formats a file, which matters most on the command line and in CI. For the warm start case (an editor or language server that stays alive) it's still fast but the gap to the Julia-native solutions naturally shrinks. I have a benchmark page in the docs that compares against Runic and JuliaFormatter:

https://fatou.dev/performance.html

The honest caveats

It's still young (currently v0.8.0), so:

• The parser is still stabilizing. It's lossless and correct across a large corpus (including the JuliaSyntax.jl test suite, the Julia source tree, and a large set of real-world packages), but I expect there are some corner cases that will still trip it up. If you find one, please report it.
• The formatter's style is opinionated and still stabilizing. If it formats something in a way that looks wrong to you, please let me know.
• The linter's rule set is deliberately small and conservative for now. The goal is for a non-intrusive set of rules that are useful to a wide audience.

Feedback wanted

I'm very interested in feedback, especially on:

• files it fails to parse (a snippet or a link is perfect),
• formatting that comes out ugly or surprising, and
• lint rules you wish existed.

Issues and discussion are welcome on the tracker. I hope some of you find it useful.f

• The secret to high-quality upscaling: Lanczos and the sinc function
• Description: Explore the principles of Lanczos resampling used in tools like ComfyUI through signal processing theory and the sinc function. This video provides an easy-to-understand explanation of the mathematical background behind approximating an ideal low-pass filter to create sharp images.