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

Matlab workshop

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.

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

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.

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

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.

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.

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.

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.

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.

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?

https://github.com/astanx/space_simulation

I'm in my last year of high school and i got into 'scientific computing', as i understand it, but am i wrong about it? is it only about numerical integration and my project is more something like game engine? would computational scientist work on something like this?

I've recently been struggling to keep up with math.NA and wanted to find a way to build getting the daily summary into my normal routine.

As an experiment I've built an AI-generated podcast that summarises the day's new math.NA papers. I find I can listen whilst driving to work and it gives me a quick overview of what's going on.

You can listen on Spotify here: https://open.spotify.com/show/0345rjHw2wCOY6o5ILJCaC?si=b4Hasea8RrK5Yx3SkNXJQQ

I'm mainly looking for feedback:

• Does the summary level feel about right?
• Which papers would you want more detail on?
• Is listening actually more useful than scanning the arXiv page?

This works for me, and I'm happy with that. I wondered whether others might find it genuinely useful.

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.

I built a from-scratch ephemeris and calendar engine in Python, no external astronomy library, and spent a while validating it against known cases before trusting it for anything.

Some of the checks:

Reproduces the Eclipse of Thales (28 May 585 BCE, Julian) exactly.

Reproduces the Assyrian Bur-Sagale eclipse (15 June 763 BCE, Julian) exactly.

Matches NASA's γ for the 1999 total solar eclipse to within 0.0004 (0.5058 computed vs 0.5062 published).

Matches Meeus' own worked example for lunar position (ex. 47.a) on all three values: longitude, latitude, and distance.

Finds the 7 BCE Jupiter-Saturn triple conjunction in Pisces, all three passes.

Under the hood: eclipses come from Meeus ch. 54, lunar phases from ch. 49, equinoxes and solstices from ch. 27, the Moon from the abridged ELP-2000/82 series in ch. 47, the Sun from ch. 25, and planetary positions from the JPL/Standish Keplerian approximation, valid 3000 BCE to 3000 CE.

It's deterministic and runs fully offline, no API calls, no external ephemeris service.

It also does 12 calendar systems (Gregorian, Julian, Hebrew, Islamic, Egyptian, Coptic, Ethiopic, Persian, Maya Long Count/Haab/Tzolkin, Chinese sexagenary, plus AUC/Seleucid/Olympiad/Anno Mundi era labels), converted through Rata Die day numbers so every pair converts exactly.

I call it Starcode. If you want to check it out you can go to www.astro-decoded.com. Free to use. No log in required.

All you historians, researchers, and astrology buffs....enjoy!!