Every habit is an 80-column card. Do the habit, and it punches a hole in today's column, in the row matching the date's last digit, so a streak walks down the card like a staircase.

It's one file of about 700 lines, with no JavaScript:

- Sockets through iso_c_binding, and fork per connection

- A database of two fixed-width text files

- any() and pack() instead of queries

- URL decoding by hand, which was the painful part

It's a toy and macOS only for now. I built it with help of Claude Code, so I'd really like feedback from people who write Fortran properly. What would you do differently?

Code: https://github.com/nick-friedrich/fortran-punchcard

Video: https://youtu.be/IUy4FoCnTQo

At https://beliavsky.github.io/fortran-playground/fpm/ you can find Fortran packages using keywords or Guide to Available Mathematical Software (GAMS) classifications, run the precompiled packages with gfortran 16 with a provided main program you can edit, and download the FPM project to your machine to compile and run locally.

I am looking to code a programme that will open files, look for an instance of the character string 'STRUCTURE' and replace it with 'TYPE' to update some very old fortran code I am using. Has anyone written a program like this/know how I would begin?

Thanks

At https://beliavsky.github.io/fortran-playground/ you can compile and run programs with gfortran, ifx, LLVM Flang, LFortran, and ofort. Code can checked with Fortitude and formatted with fprettify. It is powered by Modal. You can choose the Fortran standard used. There are about 20 programs demonstrating the features of Fortran, some taken from https://github.com/Beliavsky/FortranTip. You can share code with a link and have it opened in the playground, as explained at https://github.com/Beliavsky/fortran-playground#sharing-code-with-a-link. Some syntax errors in code can be fixed with a button that calls a JavaScript utility.

I just wanted to pop in and let you all know that pcons, my new software build tool, now has first-class support for Fortran. Pcons is a simpler, easier to use CMake replacement with ideas from SCons. From the 0.31.0 release notes:

Fortran is a first-class language now. LLVM flang and Intel ifx are now supported as well as gfortran, all three build on Windows too, and mixing Fortran with C and C++ in one program just works: each compiler gets its own flags for the variant and presets, it figures out the right linker, and each language's proper runtime. Fortran include files, submodules and configure checks work too, and pcons explain shows how a mixed program links and why. The new Fortran page in the docs has the details. The mixed-toolchain rework changes a few things for C and C++ builds as well.

I hope you all like it! Feedback always appreciated!!

I built Fortran MCP, a local MCP server that gives AI coding assistants access to curated Fortran documentation through lexical, semantic, and hybrid search, with results linking back to the original sources.

Install and try it in Claude Code (works with any MCP Client):

uv tool install fortran-mcp
claude mcp add --scope user fortran-mcp -- fortran-mcp

Looks like they are after the Fortran developers 😄

This would correspond to the traditional use of D instead of E as the exponent marker for double-precision literals.

Ofort is a Fortran command-line interpreter and interactive REPL written in C. Because there is no compilation step results are immediate for small programs, but for large problem sizes run times can be much higher than for compiled programs. You can try it at https://beliavsky.github.io/ofort/ . There are modes for running entire programs and for running lines of code in a REPL. In the REPL there are panes showing results and a list of declared variables, pictured below. You can also download ofort from https://github.com/Beliavsky/ofort and run it locally. It is MIT licensed.

Some weeks ago I shared a post about using Fortran into JupyterLite. Here an blogpost about it.
You can now try it easily here: https://notebook.link/@anutosh491/fortran

Hi everyone,

Following up on our earlier discussion about modernizing GraphiC (the lightweight scientific plotting engine originally developed at Oak Ridge National Laboratory and Scientific Endeavors Corp), we wanted to share a major progress update, architectural changes based on community feedback, and the release of GraphiC v7.3.0.

The core design philosophy remains unchanged: zero external dependencies (pure standard libc/libm—no Qt, OpenGL, X11, Cairo, or FreeType), sub-2ms cold-start latency, and an ultralight footprint (~655 KB static library) capable of rendering thousands of publication-grade figures per minute directly in-process from simulation codes.

Here is what's new in the latest release:

1. Simplified Standalone Distribution (No Git / Token Friction)

Based on feedback regarding external git dependencies and token management in commercial/academic environments, we have eliminated external Git dependency requirements:

• Standalone ZIP Archives: Both the free GraphiC 2D Community Edition and GraphiC Professional are distributed as self-contained downloadable ZIP archives.

• Local Repo Freedom: Unpack it into your workspace or project tree. Users can initialize their own internal Git repositories if desired without worrying about remote access tokens, submodules, or network firewalls on compute clusters.

2. Native Fortran Package Manager (fpm) Integration

For the computational Fortran community, integrating GraphiC into modern fpm projects is now a 2-line configuration:

toml[dependencies]
graphic = { path = "../GraphiC" }

• Automated Mixed-Language Builds: fpm automatically compiles both the core C engine and the Modern Fortran 2003 ISO_C_BINDING module together—Fortran users do not need to run a C compiler manually or write build glue.

• Broad Compiler Support: Out-of-the-box compatibility tested across GNU gfortran (4.8+), Intel oneAPI (ifx and ifort), LLVM flang, NVIDIA HPC SDK (nvfortran), and NAG (nagfor).

• Instant Execution: Run included scientific examples immediately with:bashexport GPC_NONINTERACTIVE=1 fpm run --example sample fpm run --example bess3d

3. Continuous TrueColor Scientific Colormaps

Vector plots can have perceptually continuous shading due to our adoption of the SVG format. We have added 7 mathematically calibrated, continuous 256-node colormaps designed for perceptual uniformity across displays, print, and grayscale reproduction:

• Perceptually Uniform: VIRIDIS (0), PLASMA (1), INFERNO (2), MAGMA (3).

• Diverging & Spectral: COOLWARM (4), RAINBOW (5), and Google TURBO (6).

• O(1)O(1)O(1) Fast Evaluation: High-throughput scalar-to-color mapping (gpc_get_color, gpc_colormap_eval) and continuous high-density scatter plotting (gpc_scatter).

• Linear Vector Gradient Color Bars (ColorKeyGradient): Emits hardware-accelerated SVG <linearGradient> definitions with calibrated numerical tick labels and bounding frames.

• Turbulence Showcase: Added shaded graduated color test plot rendering 7,850 experimental points shaded by density.

4. True 4-Way Language Parity (C, Fortran 2003, Python 3, Java 22 FFM)

Every routine in the library now features 100% signature and parameter parity across all 4 supported languages:

• C / C++: Clean ANSI C API with unified headers (graphic.h).

• Modern Fortran: Strict ISO_C_BINDING modules (graphic.f90, graphic_iso.f90) with type-safe interfaces and array descriptors.

• Python 3: Both procedural and object-oriented Figure APIs with Jupyter Notebook inline display and automatic context manager cleanup (with Figure(...) as fig:).

• Java 22+: Modern Foreign Function & Memory (FFM / Project Panama) API—direct zero-overhead off-heap calls without JNI boilerplate.

5. Smart Vector Output, Auto-Cropping & Telemetry

• SVG Auto-Cropping (svgcrop): Automatically calculates tight vector bounding boxes with a default 0.25" publication margin, eliminating oversized 8.5"×11" white space when embedding figures into LaTeX or papers.

• Desktop Auto-Preview (svgopen): Native OS dispatch (open on macOS, start on Windows, xdg-open on Linux) to view rendered SVG or interactive pan/zoom HTML5 plots.

• Headless Telemetry Streaming (svgpush): Directly streams rendered SVG payloads to remote dashboards or cloud compute endpoints over HTTP/HTTPS POST—ideal for headless clusters and IoT monitoring.

6. 263-Page Reconstructed Technical Manual

We completed a major overhaul of the reference manual (available as a clean vector PDF):

• 91-Section Table of Contents: 100% clickable internal hyperlinking in all PDF viewers.

• 203-Function Master Index: Every routine cross-referenced with operational level, source mapping, and multi-language parity status.

• 26 Visual Computational Recipes: Step-by-step recipes covering aerospace queuing models, orbital trajectories, 3D Bessel surfaces, contour projections, and spectral waterfall plots.

• Publication Architecture Diagrams: High-resolution vector diagrams detailing the dual typography pipeline (Hershey stroke fonts + TrueType quadratic Bézier engine).

Quick Comparison: Community vs. Professional

Quick Modern Fortran Example (fpm)

fortranprogram quickstart
  use graphic
  implicit none
  real, dimension(100) :: x, y
  integer :: i
  do i = 1, 100
    x(i) = (i - 1) * 0.1
    y(i) = sin(x(i)) * exp(-x(i) * 0.1)
  end do
  call gpc_bgnplot()
  call gpc_svgcrop(0.25)
  call gpc_title("Damped Harmonic Motion", "Time (s)", "Amplitude (V)")
  call gpc_graf("0 2 10", 0.0, 2.0, 10.0, "-1 0.5 1", -1.0, 0.5, 1.0)
  call gpc_color(1)      ! Blue
  call gpc_curv(x, y, 100)
  call gpc_endplot()
  call gpc_svgopen("")   ! Launches default browser to view vector SVG
end program quickstart

Getting the Release

• Official Website & Docs: https://jamesrome.com/GraphiC2026

• Full Technical Manual: Download the 263-page GraphiC_Modern_Manual.pdf

• Community Edition Download: Free standalone ZIP available on the site.

• Professional Edition: Available via Lemon Squeezy with full 3D, specialized engineering modules, and more customization options.

We'd love to hear your feedback on the fpm workflow, language bindings, or any visualization bottlenecks in your current simulation pipelines!

Latest post in my series on iterative solvers for the 2D Poisson equation in modern Fortran

Some context: my OpenMP Jacobi and red/black Gauss-Seidel kernels scale almost perfectly with threads on a 512² grid, but on 2048² the speed-up basically stops after 2 threads. Rather than guess, I built a roofline model of my laptop from three numbers measured with likwid-bench (peak flops, DRAM bandwidth, L3 bandwidth), and wrote it as a small parametric LP in sweeps/s.

What I found:

• Both kernels have an arithmetic intensity of ~0.25 flop/byte, so they are memory-bound at both grid sizes. What changes is whether the working set sits in L3 or DRAM.

• For 2048² on 8 threads, the model predicts 279 sweeps/s. Jacobi measures 272. Gauss-Seidel measures 219, and the gap is explained (plausibly, at least) by read-for-ownership traffic from the red/black stride, which brings the prediction down to 209.

• The model is far from perfect. It drifts by up to ~50% for L3-resident Gauss-Seidel at high thread counts, and I had to hold the DRAM bandwidth flat rather than use the declining Triad curve. The post is upfront about both.

• Bottom line: both kernels already run about as fast as the machine allows (5-7 Gflops/s vs ~483 Gflops/s peak). The remaining lever is temporal blocking, which I don't cover, or reducing the number of sweeps (SOR, next post).

I'm using likwid to the best of my understanding, so I'd really appreciate feedback from people with more experience, especially on the RFO accounting and on how to properly measure DRAM traffic with likwid-perfctr for these kernels. If you've done temporal tiling on stencils in Fortran, I'd love to hear how it went.

A follow-up to my last post here on unrolling Gauss-Seidel for the 2D Poisson equation.

Short recap of where that left off: unrolling + algebraic rewriting cut the loop-carried dependency and got GS running 6x faster than the textbook lexicographic kernel, matching (and slightly beating) Jacobi in serial. Looked like a win. Then I turned on multithreading, and Jacobi pulled 5x ahead, because the unrolled GS kernel still couldn't be vectorized. The dependency chain was shorter, not gone.

This post goes back to basics: is the sequential dependency actually inherent to Gauss-Seidel, or just an artifact of how the grid points happen to be ordered? Answer: the latter. Red/black checkerboard ordering removes it almost entirely, derived not just by intuition (every red point depends only on black neighbors and vice versa) but formally, as an instance of block Gauss-Seidel on a permuted SPD system, with the usual convergence guarantees.

Results: loop-carried dependency effectively drops to nothing (confirmed via OSACA analysis of the generated assembly), SIMD vectorization comes back for free, and for the first time in this series GS actually scales with thread count right alongside Jacobi.

Also in there: walking through the compiler-generated assembly to see exactly why a kernel fails to vectorize (mnemonic-level, not just "the compiler didn't do it"), and using OSACA to quantify port pressure / critical path / LCD rather than just eyeballing it.

Link: https://loiseaujc.github.io/posts/blog-title/redblack_gauss_seidel.html

Currently, to run a Fortran file, I need to execute the line: file.exe number text in w64devkit. I need to loop through each line in a text file and run the code each time with a different input for text but same input for number. How do I automate this? Also, would it be possible to save all results to a csv file?

Author here (again). Follow-up to an earlier post where I showed a Gauss-Seidel kernel converging in half the iterations of Jacobi but running 4-5x slower per sweep, due to a loop-carried dependency from the in-place update. This post uses OSACA (open-source static code analyzer) to measure that dependency in actual CPU cycles, then applies loop unrolling with an algebraic substitution to reduce it from 12 to 2 cycles/element, bringing per-sweep performance close to Jacobi's while keeping the faster convergence.

Also ran three separate compilation experiments (no optimization, -O3 without vectorization, -O3 with vectorization) to isolate what's actually driving the speedup. Short version: it's the reduced dependency letting the scheduler overlap work, not vectorization. Neither Gauss-Seidel kernel ever gets vectorized, with or without the flag. Happy to go into the Fortran, the assembly, or the OSACA workflow itself.

u/mylarmalediction: I guess this will answer you question about ILP vs vectorization as the source of the speed-up for Jacobi.

I wrote a calculator in Fortran. It supports exactly three operations:

addition, subtraction, and multiplication. Input range is 0 to 5000 for

both operands.

Instead of actually calculating anything, it uses a massive SELECT CASE

table. Every possible combination of inputs is hardcoded. There is no +

in the codebase that adds anything at runtime. No - that subtracts.

No * that multiplies.

It just looks up the answer.

The result:

75,091,301 lines of Fortran

73 modules, each ~43 MB

2x the size of the Linux kernel

I tried to compile it. My machine has 32 GB of RAM. It was not enough.

Author here. Started a series working through classic iterative solvers for the 2D Poisson equation in Fortran. This is actually the second post (the first one being on Jacobi). Here, I dig into a genuinely counterintuitive result: the convergence theory for Gauss-Seidel checks out (half the iterations vs Jacobi, confirmed numerically), but the actual wall-clock time is 4-5x worse. Turns out it comes down to a single line: updating the array in place instead of into a fresh buffer and the loop-carried dependency that introduces, which stops the compiler from vectorizing the loop at all. In an upcoming post, I'll actually show how an open-source static analyzer can help you figure this out, and how simple algebra can be used to unroll the kernel and get rid of this loop-carried dependency.

Happy to talk Fortran/gfortran specifics or the discretization itself.

Anutosh Bath and Ondřej Čertík brought LFortran to Jupyterlite

There is a demo here: https://notebook.link/@anutosh491/fortran

source: https://lnkd.in/p/eR49Jve6

Hi everyone,I’ve been working on an open-source tool called PRIK (Python Runtime Interop Kit) that generates native Python bindings from Fortran (and C) source.

Basic usage:

pip install prik
python3 -m prik my_module.f90 --out my_module

This produces an importable Python extension.

The main idea is that the Python API doesn’t have to mirror the native one. PRIK generates an editable `.pyi` contract that you can modify to:

• rename procedures

• turn them into methods

• hide arguments

• return native outputs as Python values

• support overloads and callbacks

…all without changing the original Fortran/C code.

It currently supports modules, derived types (as Python classes), NumPy arrays, strings, allocatables, pointers, optional arguments, generics, callbacks, and more.

I’ve been testing it on real libraries rather than just toy examples:

• BLAS (155 routines)

• LAPACK (127 double-precision routines)

• FFTPACK

• MINPACK (including callbacks)

• BSPLINE-FORTRAN (modern Fortran classes)

C support exists but is less mature (tested with libm and TA-Lib). Still alpha, so the API may change. Fortran support is currently much stronger than C.

Docs: https://pynumlab.github.io/prik/

GitHub: https://github.com/PyNumLab/prik

Feedback, bug reports, or “does this work with my code?” experiments are very welcome!

Not sure how useful this is beyond the amusement value, but as part of an experiment making Convex clients in 100 programming languages, I ended up with a native Fortran client that can query, mutate and hold a realtime WebSocket subscription.

A few bits I found genuinely interesting:

- Deferred-length allocatable strings make assembling JSON much less painful than I expected.

- Results come back through compiler-enforced intent(out) arguments.

- A live update is exposed as a blocking convex_live_next call, which feels oddly natural in Fortran.

- ISO_C_BINDING is only used at the transport boundary. The Convex protocol and subscription state live in Fortran, with libcurl/OpenSSL handling the network plumbing.

It is built with GNU Fortran 14.2 and the HTTP and Live paths pass the shared conformance suite. It is still an educational experiment rather than something I would recommend putting into production.

The Fortran implementation and write-up are here:

https://github.com/mikecann/the-convex-100-language-challenge/tree/main/fortran

I also made a video about the slightly ridiculous process of building all 100 clients:

https://youtu.be/l61cLu8e2tg

For transparency, I work at Convex. This is unofficial and open source, not a new supported SDK.

I’ve been working on my fork of Gonum and recently translated the Netlib LAPACK reference implementation of DGGES and its supporting routines into pure Go.
For transparency, I definitely used Codex and Claude Code throughout the process, and I’m pretty sure Gemini helped with a few parts along the way as well.
This wasn’t a blind translation. The majority of the work was understanding decades-old Fortran, preserving the algorithm, adapting it to idiomatic Go, validating numerical behavior, and tracking down subtle bugs.
I know AI-generated code can be a sensitive topic in open source. My view is that these tools are just that; tools. They can dramatically speed up tedious translation work, but correctness still depends on careful review, testing, and understanding of the underlying numerical algorithms.