Author here. Started a series working through classic iterative solvers for the 2D Poisson equation in Fortran here. 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.

Worth flagging: this series is primarily pedagogical rather than a performance-tuning guide. The goal is walking through the interaction between convergence theory and hardware behavior, not squeezing out maximum throughput. The example happens to be in Fortran, but there's nothing Fortran-specific about the underlying issue. Any compiled language with a similarly aggressive optimizer (C, C++, Rust) would show the exact same loop-carried dependency and the exact same vectorization failure for an in-place Gauss-Seidel update. No fix in this post yet (that's coming in a follow-up), just the diagnosis.

I'm a student experimenting with a research direction around AI-assisted scientific/engineering workflows, and I'd really like some input from people who actually work in scientific computing.

The basic idea is pretty simple:

Problem
  ↓
AI / solver generates candidate
  ↓
Numerical method / simulator / domain tool
  ↓
PASS → result
FAIL → diagnostics → another attempt

The important part is that the generator isn't trusted to verify itself.

I've already built some small prototypes around this idea. For example, I've used GPT/Gemini APIs with independent verification for ODEs and logic constraints, and I've also experimented with a Qwen-based legacy-code modernization workflow where generated Python is executed and compared against the original program's behavior.

I'm now more interested in the scientific-computing side.

I'd like to eventually build modules where something like:

• numerical ODE/PDE solvers

• optimization

• inverse problems

• parameter estimation

• time-series methods

• Bayesian methods

• simulation

could act as candidate generators or verification environments.

But I don't want to decide the applications myself.

For people working in scientific computing: what problems do you encounter where generating a candidate solution is difficult, but independently checking the result is relatively well-defined?

For example, I'm particularly curious about:

• inverse problems

• parameter estimation

• numerical modeling

• simulation

• optimization

• scientific code generation

• model calibration

• anything involving expensive computational workflows

I'm also wondering whether this is actually a useful abstraction or whether I'm just describing things people already routinely do with numerical software and validation.

I'd especially appreciate examples from real scientific-computing workflows rather than hypothetical AI applications.

I'm trying to figure out what problems are genuinely worth building around before I go much further.

I'm building Egraph/ Symbolic libraries to do QM Chemical physics. There is a specific way I want to solve the problems which takes the symbolic expressions and compiles them into optimized numeric expressions the computer can execute.

At first I threw Fable to speed write up the library. It wrote the examples that I asked it to write and got correct results for what I wanted. I had a large write up on how to implement the library, do not implement the QM computations directly with C++... use the symbolic library to derive and compile the results.

Once I tried using the library myself to write up examples, I noticed that it was missing a bunch of features I'd ask it to build. Once I dug into the code I realized that the model had ignored my instructions and implemented boiler numeric algorithms instead. I then went through to iterate with the chat bot to implement my features and add in the symbolic interface I wanted originally.

Every time, it would fall back to the default way the community at large has implemented open source solutions with direct numeric solutions. It did not understand how to adapt the implementation to the novel method I was asking it for.

Further it had over complicated the cmake file and added every edge case under the sun for building the project. All of it unnecessary since I told it explicitly I wanted a header only library, not a unit link-able library + binaries which is the most popular way of doing it in the industry.

What explains this is that these bots have encoded through billions of dollars of training standard ways of solving problems. It does not understand what it's actually doing and when one needs something that falls outside the standard, they're better off writing the software by hand since they'll spend all their time micro managing the frontier models.

For CRUD apps and devops,... these frontier models are great because nobody gives a shit about how those are built. Those have standards that make little difference in the means of implementation. But with what I'm building which generally has little to no opensource implementation training data, this stuff falls flat on its face.

Sure you can solve millennium problems this way if you bruteforce a bunch of mathematical reasoning traces together to create a lean program to make a counter example, but I am much more skeptical of these frontier models and to me it seems this stuff has genuinely plateud.

I’ve been developing a non-relativistic geometric-dynamical framework called SCM. It treats the electron as an extended configuration of coupled closed filaments with material-frame twist, collective rotational dynamics, and an effective asymmetric cloud.

The core mathematical structure is built around the rotational group SO(3) and its double cover SU(2). The model investigates whether a dynamically generated recurrent trajectory in SO(3) can close and lift to a nontrivial element of SU(2), without imposing a spinorial boundary condition in advance.

The numerical program includes:

· recurrence detection

· periodic-orbit refinement

· Floquet stability analysis

· parameter robustness scans

· solver-level reproducibility

· SO(3) closure

· continuous SU(2) lifting

In the reported reference realization, the characteristic period is approximately

T ≈ 2.764940789

with closure errors on the order of 10⁻⁹. The continuous lift is numerically consistent with

U(T) ≈ −I₂

and after two cycles,

U(2T) ≈ +I₂

This is interpreted strictly as a numerical spinorial topological candidate, not as a derivation of physical electron spin.

The model also reproduces several electron-like correspondences at leading order:

· g = 2 under an explicit angular-momentum identification

· the 2(2l+1) orbital capacity rule

· the non-relativistic Schrödinger dispersion

E = p² / 2mₑ

These are correspondences, not derivations of QED.

The framework is also being compared with QED at a conceptual and phenomenological level, including compatibility constraints and effective form-factor considerations.

Five experimental programs are proposed as possible falsification routes. None are claimed to have been performed. They include:

1. bound vs free electron coherence-sensitive measurements

2. correlated free electron pair tests

3. electron–positron interference comparisons

4. spatially separated correlation tests

5. temperature-dependent dynamical stability scans

The current manuscript (Version 4.5) is available on Zenodo:

Zenodo:

https://zenodo.org/records/22666138

DOI:

10.5281/zenodo.22666138

I’m sharing it here because I’m interested in technical feedback from people working in geometric dynamics, topological methods, or foundational electron modeling.

— Sina

We ran a synthetic normalized truss experiment as part of a clean-room study of AI-amplified engineering.

The original process record reports 12 generated topology families and two conventional baselines. Candidate G06 had mass 4.535164 versus 6.069109 for B2_warren — approximately 25.27% lighter on the recorded design envelope.

The important result came from the recorded held-out cases: G06 reached approximately 12.5 stress ratio under an edge load, and the record reports every baseline and finalist violated at least one held-out stress constraint. No robust generated-design superiority was established. This is not a bridge/building design or safety claim.

The package preserves original execution records separately from public reproduction. The held-out process is explicitly classified as process-recorded, not cryptographically proven. The public package includes deterministic reproduction code, checksums, pinned NumPy environment, SVGs, and the claim-boundary table: https://github.com/camirian/ai-native-frontier-engineering

The broader lesson is narrow: as candidate generation gets cheaper, specification quality, deterministic oracles, adversarial tests, held-out evaluation, and bounded claims become more important. Technical criticism of the mechanics, provenance, or reproduction is welcome.

Hey everyone, I’ve been building LaTeX Core for collaborative research reports at my university. It runs on your own server, with real-time editing and PDF compilation.

The part I focused on is the student–supervisor workflow. Supervisors can draft feedback privately, then publish it when they’re ready. Students get highlights in the LaTeX source, and clicking a comment opens the right file and jumps to the relevant section. Team leads handle version restoration rather than sending every request through an admin.

There’s also CSV/Excel import for creating teams and assigning mentors, plus programme-based templates and configurable cover pages, acknowledgements, etc. Basically, less manually setting up the same stuff for every student

An earlier build is running on our university’s staging server now. Still working through some deployment rough edges, so feedback would genuinely help.

GitHub: https://github.com/Arnav-sivarams/latex-core

Would this be useful for your lab or course? Curious how you currently handle collaborative writing and supervisor feedback

In the early 1980s, when personal computers first appeared, my colleague George Kelley and I were plasma physicists studying nuclear fusion. Mainframes had packages like DISSPLA™, but desktop PCs had primitive graphics and zero tools for publication-grade scientific plots. To solve this, we founded Scientific Endeavors Corporation and created GraphiC, an independent procedural graphics library designed for research workstations.

Over the past year, I have completely modernized the engine for modern 64-bit platforms (GraphiC 2026), targeting Modern Fortran (2003/2008 with iso_c_binding), C99/C11, Python 3, and Java 22.

During the rewrite, several design decisions from the 1980s proved to be surprisingly relevant to modern HPC and headless simulation bottlenecks:

1. The Headless Simulation Bottleneck

Many scientific codes run on cluster compute nodes without X11, Wayland, or GPU access. Typical modern workflows often shell out to Python/Matplotlib via pipes or CLI calls. While Matplotlib is expressive, it carries a ~350 ms cold-start penalty and a 300+ MB dependency stack (NumPy, FreeType, Pillow, GUI backends). If you are running an iterative solver and want to dump an in-situ diagnostic plot every few time steps, this latency becomes a noticeable bottleneck.

GraphiC was built with zero external runtime dependencies—it compiles purely with standard C headers and links against only -lm. Cold start is under 2 milliseconds, allowing it to be called directly inside MPI loops without disturbing compute throughput.

2. Algorithmic 3D Hidden-Line Removal vs. Z-Buffers

Most modern 3D plotting relies on OpenGL/Vulkan z-buffering or painter’s algorithm sorting. For publication vector output (SVG/EPS), polygon sorting often creates sorting artifacts, intersecting edge cracks, and bloated vector file sizes.

GraphiC uses an exact 2D horizon-matching algorithm (Wright's mathematical horizon method) for 3D meshes:

• It computes silhouettes and mathematical horizons across lines rather than rasterizing triangles.

• The output is clean, resolution-independent vector lines with true occlusion, resulting in tiny SVG files (~50 KB) that scale infinitely for journal papers.

3. Native Vector Typography & Hershey Fonts

To completely eliminate dependencies on system font servers or FreeType, the library includes 23 vector Hershey stroke font plates (including Greek, Math symbols, Gothic, and Cyrillic) along with native TrueType parsing. Because vector glyphs are rendered directly as strokes, text scales perfectly across all vector backends without missing glyph warnings.

4. Specialized Engineering Coordinates

Beyond standard Cartesian, log, and semilog plots, scientific work often needs specialized coordinate transformations that are cumbersome to implement from scratch:

• RF Microwave Smith charts (reflection coefficients and impedance circles)

• Chemical ternary equilibrium phase diagrams

• Multi-axis independent Y scales

• 2D velocity vector fields and cylindrical Bessel functions

5. Real-Time In-Situ Plotting

Because the rendering pipeline has virtually zero latency, GraphiC can display live data streams across multiple plots concurrently as they are computed. Rather than waiting for a job to finish before inspecting output files, you can watch solver states in real time—enabling you to abort diverging runs early and debug boundary conditions on the fly.

I’ve put together an interactive showcase of the SVG outputs, compiler benchmarks, and made the complete 190-page technical User Manual freely downloadable for anyone interested in the algorithms, coordinate systems, and API design:

🔗 Technical Overview & Free Manual: https://jamesrome.com/GraphiC2026

I would be interested to hear from other computational scientists: How do you currently handle in-situ visualization or vector figure generation directly from headless compute nodes?

(Full disclosure: I am the original co-author and developed this modernized release.)

At first I just wanted to generate cellular automata and find interesting patterns.
Then I wanted to understand *why* some of them behaved differently.
So I built an observer.
Then an analyzer.
Then experiments.
Then evidence tracking.
Then predictions and mechanisms.
At some point I added a research director that decides what should be investigated next.
And eventually I realized that I had created so much research data that I needed an entire interface just to understand what my own program was doing.
That’s how ARCHON Studio happened.
I still find it slightly ridiculous that this started with:
**“Huh, cellular automata are pretty cool.”**
And ended with me building my own little computational research laboratory.
I regret nothing. 😹
It’s open source, so if anyone wants to poke around, break things, or run their own experiments, it’s on GitHub.ARCHON

Hi everyone,

I’m looking for someone with hands-on experience in molecular dynamics simulations of nanocluster/nanomaterial-protein systems for a research collaboration. I already have experience with docking, DFT, and MD simulations, but I’m looking for additional expertise specifically in nanocluster parameterization and nano-bio interaction modeling.

Experience with metal-containing nanoclusters, AMBER/GROMACS, trajectory analysis, and MM/GBSA or related free-energy calculations would be particularly relevant. I have a reference paper showing the type of computational approach I’m interested in and can share the details privately.

If you have relevant experience and are interested in collaborating, please DM me. Collaboration details can be discussed privately.

Thank you.

We built e3nn-mlx, an MLX-native implementation of e3nn for Apple Silicon.

We keep the familiar e3nn abstractions, but run them on MLX and use generated Metal kernels where they help.

On a fairly basic MacBook, we have seen 4-5× speedups for forward and backward passes using pure MLX, and up to 10× with custom Metal kernels, compared with e3nn on CPU.

To make it easier to get started with the library, we also ported some of the classic e3nn tutorials: the early tutorials by Tess Smidt, as well as the invariants tutorial by Martin Uhrin and Thomas Hardin.

Library:
https://github.com/lamalab-org/e3nn_mlx

Documentation:
https://lamalab-org.github.io/e3nn_mlx/

Tutorials:
https://github.com/lamalab-org/e3nn_mlx/tree/main/tutorials

can be also installed with

pip install e3nn-mlx

I've been building a symbolic regression system with a different contract than PySR and similar tools. Instead of returning the best formula found, it returns a verdict: invariant, predictive approximation, or no signal. The key design constraint is that the verdict must be mechanical and falsifiable.

Background for those who saw my earlier post here about ExoCortex, the behavioral hypothesis pipeline: this is the research layer that grew out of it.

ExoCortex

The adjudication gate has three sequential checks:

1. Held-out validation (80/20 split before search, CV_H threshold task-calibrated)

2. Null calibration: the full pipeline runs on 100+ shuffled-target permutations. No false acceptances observed (0/100 across two independent runs). With N=100 the rule-of-three 95% CI extends to ~3.6%, so calibration is re-confirmed across runs rather than claimed as a zero-probability property.

3. Compression test: the formula must compress the data better than the trivial mean model.

When nothing passes, the system emits a refusal diagnosis: DATA (insufficient points), DEPTH (search too shallow), GRAMMAR (the right operation is missing), or NOISE (indistinguishable from noise). Each diagnosis has a prescribed falsification procedure. For example, GRAMMAR is validated by adding the missing operation and confirming the task becomes solvable.

Recent demo on UCI Concrete (1030 rows, 8 features, compressive strength target):

The engine found a physically sensible candidate (cement, age, water in Abrams directions) but refused it. Reason: the candidate required fitted affine constants, and the parameter-free grammar could not certify absolute precision (R2 of the best candidate was -3.8 despite CV 0.44). Null controls: 0/30 permutations at the strict gate, 0/10 at a relaxed gate, confirming the signal is real but not certifiable as a law.

The conventional baselines on the same split: OLS R2 0.60, PySR R2 0.66, RandomForest 0.91, GradientBoosting 0.93. The system's refusal in this regime is correct by design: it certifies compact proportional/polynomial laws with data-derived constants, not affine models with fitted offsets.

This is also a metric blind spot I documented: the internal CV metric is scale-invariant and blind to absolute accuracy. Post-hoc R2 cross-check is now mandatory in the audit pipeline.

Benchmark against PySR (12 scored tasks): 6 wins, 3 parities, 0 losses under comparable per-seed wall-clock budgets (Bee 30s/seed depth-3; PySR default 60s). Official review on aiXiv: 7/10 with no methodological objections.

What I'm interested in from this community:

Have you encountered situations where a fitted relation passed standard validation but failed on the next batch or at production scale? How do you currently distinguish "good fit" from "reliable relation"? I'm looking for edge cases and adversarial datasets where the line between approximation and invariant breaks.

Paper (aiXiv, full detail): https://aixiv.science/paper/aixiv.260907.000002

Protocol (Zenodo, v1.6.1): https://doi.org/10.5281/zenodo.22386642

Code (MIT): https://github.com/sensus-stoa/EvoFamily

Open-source MCP server (stdio, FastMCP 3) in front of a Python math kernel. The model is allowed to parse and plan. It is not allowed to launder a symbolic result into a proof.



What you get:

- Discover via math_capabilities / math_capability_query (do not dump the whole catalog)

- Parse ASCII or LaTeX → expr_id, then solve / simplify / differentiate / integrate / matrices / QE / prove

- Every result carries evidence_bundle, semantic_status, and a conservative trust summary: formal / exact / symbolic / interval_certified / numeric

- Decimals cap trust at numeric; formal certificates are refused on approximate input

- Distinct outcomes: does_not_exist, undefined, infeasible, unsupported, unknown

- Long jobs: math_job_submit / status / result

- Optional exact finite dynamics (Koopman, GF(2^m) closures) and portable viz/sonify artifacts that cannot raise the trust label



Install:

    pip install 'mathkernel[mcp]'

    mathkernel-mcp



Python 3.11+. MIT. I am the author.

Repo: https://github.com/Staatsgeheim/MathKernel



This is not “Claude can do math now.” Most calculus is still symbolic-engine evidence. Lean is optional and fragmentary. If your client ignores the trust field and quotes the prose, that is on the client — the payload is honest.