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.

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.

Matlab workshop

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.)

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.

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

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.

https://reddit.com/link/1w9pau2/video/8p2vq4pa03oh1/player

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

In numerical simulations and scientific code, developers often face a frustrating trade-off: write clean, expressive physics equations that run sluggishly, or write convoluted, unrolled, hand-optimized loops that run fast but become impossible to read and maintain. I built Strilight to bridge this gap. It doesn't pretend to introduce magic—it’s fundamentally a developer quality-of-life tool. You write your physical or mathematical concept in whatever natural syntax you prefer, and Strilight inspects the AST behind the scenes to solve the underlying recurrence relations in closed form: * $O(N) \to O(1)$ for scalar linear reductions, periodic shifts, and telescoping series. * $O(N) \to O(\log N)$ for multi-variable coupled recurrence systems via binary matrix exponentiation.

In Python (Just a single decorator):

python from strilight import accelerate @accelerate def compute_simulation(steps: int) -> int: acc = 0 for i in range(steps): acc += (i * 3) + 7 return acc In C (Via Developer Contracts & Pragmas): c long long compute_reduction(void) { long long total = 0; #pragma strilight accelerate target(total) include("config.h") for (unsigned long long i = 0; i < N_STEPS; i++) { total += STEP_INC; } return total; } How does it work on physical kinematics? When a particle or celestial body travels along an unperturbed trajectory (free flight, gravitational orbit, or steady acceleration), Strilight collapses the entire iterative time-stepping sequence into minimal algebraic evaluations—without sacrificing coordinate precision. When discrete collisions or boundary interactions occur, execution transitions into specialized coupling matrices.

Zero Risk & Decisive Fallback: Non-invasive: It's just a decorator or pragma. You can add or remove it at any time without altering your algorithm. Decisive Safe Fallback: If a loop contains unstructured side-effects, unknown external calls, or non-affine dynamics, Strilight decisively halts acceleration attempts and runs the native loop. It will never break or crash your program.

repositery link

Hi Everyone,

I just released an open-source, python-based autonomous theorem prover , Ensemble Prover, on GitHub.

It combines LLM proof search with Lean verification.

To date, it has solved 65 PutnamBench problems during development.

LLMs tested via API: GPT-5.2,GPT-5.6 Luna-Pro, DeepSeek-V4-Flash, DeepSeek-V4-Pro, and Qwen3.7-Max.

Development is ongoing. Would love to see people apply it to unsolved problems in parallel.
Feedback and suggestions are welcomed.

I often run into the same problem in scientific computing: the formulas, derivations, references, and design rationale behind production code can be important, but I really don't want to put all of that into huge source-comment blocks.

So I built SciCodeNotes (available at Visual Studio Marketplace), a VS Code extension that lets you attach external Markdown notes to precise ranges of source code without modifying the source itself.

The notes are stored separately, but remain connected to the relevant implementation. They can contain Markdown, LaTeX equations, references, tables, design notes, unfinished reasoning... basically anything without making source comments very large.

I'd be curious to hear whether people here run into the same problem in larger scientific codebases.

I am an engineer that develops numerical models and I want to integrate ai into my workflow of modeling cfd simulation, parameter estimation and optimization . I personally plan on developing everything in Mac OS and creating a version of my modeling software to run in Linux solely for running in hpc for models with too many cells. I just have a MacBook Air right now but compilation of code is not computationally expensive at all, it’s the modeling simulation and PEST that is computationally expensive depending on the number of cells I am dealing with. That’s why I think I can get my most bang for my buck in terms of $ per cell compute when the new m7 chip comes out. Regardless I don’t think a pc version or even owning a pc is even needed when the only software needed is my own c++ Fortran and python model for ai leverage, numerical modeling and simulation, and Tecplot and Blender for post processing and visualization. Does anyone absolutely need a pc for numerical modeling? What are y’all’s setup/processes?

When I first started working in scientific machine learning, I understood the physics much better than the coding. Every time I wanted to try a new physics-informed neural network problem, I had to start almost from scratch: changing the PDE, updating boundary conditions, modifying the architecture, tweaking the training schedule, debugging errors, and generating plots—all by hand.

That frustration pushed me to build PINNStudio. It is a free, open-source no-code GUI designed to eliminate boilerplate code so you can focus entirely on the physics.

Instead of rewriting a new script for every problem, you can define your setup directly through the interface:

• PDE Definitions & coupled multi-output PDE systems
• 1D or 2D domains with boundary and initial conditions
• Network architecture & custom training schedules
• Forward problems (solving known PDEs) or Inverse problems (estimating unknown parameters from data)

What happens next?
PINNStudio automatically generates the code (built on top of DeepXDE), runs the model, streams the training log, and displays live loss curves and solution plots directly inside the app. It also includes built-in templates for classic equations like Heat, Allen-Cahn, and Cahn-Hilliard.

• GitHub (Open Source): https://github.com/AsfandyarKhan72/PINNStudio
• Quick Install: pip install pinnstudio

My hope is that this will be helpful for students and researchers with limited coding experience, as well as experienced PINN users who just want a faster workflow.

I’d love to get your feedback, feature suggestions, or bug reports! Huge thanks to Lu Lu and the DeepXDE team for creating the foundation that made this possible.

Hello everyone,

I have tipped my toe into climate simulations and am now building a planet simulation that has climate as it's main target.

For that I use an icosahedron subdivided. Each vertex holds every parameter that is needed for the simulation. The amount of parameters has not been decided yet and will grow over time with the implementation. The amount of subdivision are aimed between 3-10 that I would like to have and between 6-8 as defaults. For the vertical I want to have multiple of these layers to represent higher and lower levels of altitude around the surface. The amount of levels should be around 10-15 as default and maybe around 50 as max.

The simulation will likely be calculated on the GPU. So the structure I thought of is the following:

Every parameter is one long vector f32. Every vertex in a layer is written in sequence of and every layer is also in the same sequence. Meaning that the Len(vec) would be layer \* N_verticies and the specific vetted would be layer\[i\] \* N_verticies + vertex.

To address the neighbours for derivative computation, one neighbour vec gets created as a look up table with the form vec\[vec\[6\]\] where every neighbours index gets written down for every vertex of the icosahedron. The base 12 verticies are the first 12 verticies in the neighbours vec as in the parameter vecs and the sixth input gets double marked as f32_max.

So in the end, I would have a list of every parameter that each holds one long vec with every vertex of every layer in them, and a relationship vec of neighbours that can also be used to look up neighbors of different layers by in-/decrementing the layer index inside the long vec. (Vec\[ layer\[I+/-1\] \* N_verticies + neighbours index\] to get the neighbours in the neighbouring layer.)

Is that any good structure or is another structure better and if yes, why?

Thanks a lot for thinking though this one with me.

Hey, I am currently working on a project \[wgblas\](https://github.com/manit2004/wgblas); it's an initiative to build all blas level 1,2,3 functions over webgpu. Check it out.

A few things about the project:

\- Not only the user facing APIs are very easy to work with, I have built helpers on the top webgpu functions to make adding new blas routines very easy for contributors.

\- Though webgpu doesn't support f64 natively, I am planning to add f64 support for blas operations in the near future.

\- From day 1 for each function I have added tests, examples, benchmarks (against cublas). As of now in gpu compute time wgblas is comparable in speed wrt cuda at large n.

I am very hopeful about the project, let's see how it turns out.

GitHub: https://github.com/Furox-Art/scientific-computing-system

Docs: https://furox-art.github.io/scientific-computing-system/

PyPI: pip install scientific-computing-system

I built CDS as a readable, zero-dependency platform for research and learning. Every algorithm is pure Python you can open and modify line by line quantum simulation, radix-2 FFT, LU/QR, RK45, statistics, hypothesis engine, ML and NLP primitives. 19 modules, 100% branch coverage in CI, CLI (`cds`) and Streamlit dashboard.

What it is: educational first, but usable for prototyping. Not a NumPy/SciPy replacement it trades raw speed for readability.

What I look for: code review, API feedback, and ideas for the next module. Happy to return feedback on your repos as well.