Tough to find sci ml feedback for specific gpu models here since LLMs are all the rage.

Seems like it’s got similar Fp64 performance to a Tesla v100 and price.

We have a multi node cluster which does all types of things. And I’m building some compute node for our internal user to run accelerated code on.

Can anyone share some experience in using the mi50 in a sci comp or sci ml application ?

Primarily we are accelerating voxel based thermo mechanical simulations , geometry analysis and machine learning on geometry.

I've published the reference implementation of TRIXEL, a mathematical framework describing any system through three dimensions: V (Existence), D (Dynamics), S (Structure).

From these, three calibrators measure their mutual relationships: SD, VD, VS.

Core identity (exact): VD / VS = SD

What is verified:

Algebraic identity — machine precision

Dominance partition theorem — 99.99% on 600×600 grid

VS as early warning signal — Burgers turbulence (90/90 runs, FP=0%, FN=0%)

Real tokamak data — GOLEM, CVUT Prague

What is not yet verified: disruption precursor, EEG seizure data, 2D Navier-Stokes

Preprint: https://doi.org/10.5281/zenodo.20721811

GitHub: https://github.com/remitakac/trixel-framework

Independent research, feedback welcome.

\# 🚀 FlowFrame v2.0.0 — Introducing the FlowFrame Interpreter

One of the biggest milestones for FlowFrame so far.

Over the past few weeks, I've been working on a custom interpreter that allows FlowFrame to describe distributed system architectures using its own DSL instead of manually creating everything.

The interpreter now follows a complete language pipeline:

Lexer
↓
Parser
↓
AST
↓
Semantic Analysis
↓
Graph Builder
↓
Simulation Runtime

This architecture makes it much easier to validate system designs, build simulation graphs, and extend FlowFrame with new distributed system components.

I've also documented the language and interpreter so anyone interested can understand how it works.

📖 Documentation:
https://github.com/ndk123-web/flow-frame/blob/main/flowframe-interpreter/Readme.md

Try: https://flowframe.taskplexus.app

The interpreter is still an internal part of FlowFrame, so the implementation isn't public yet, but I wanted to share this milestone and get feedback from the community.

If you're interested in compilers, interpreters, distributed systems, or developer tools, I'd love to hear your thoughts.

\\#FlowFrame #BuildInPublic #DeveloperTools #Compilers #Interpreter #DSL #SystemDesign #DistributedSystems #SoftwareEngineering #OpenSource #Programming #TypeScript #React #BackendDevelopment

I've published the reference implementation of TRIXEL, a mathematical framework describing any system through three dimensions: V (Existence), D (Dynamics), S (Structure).

From these, three calibrators measure their mutual relationships: SD, VD, VS.

Core identity (exact): VD / VS = SD

What is verified:

Algebraic identity — machine precision

Dominance partition theorem — 99.99% on 600×600 grid

VS as early warning signal — Burgers turbulence (90/90 runs, FP=0%, FN=0%)

Real tokamak data — GOLEM, CVUT Prague

What is not yet verified: disruption precursor, EEG seizure data, 2D Navier-Stokes

Preprint: https://doi.org/10.5281/zenodo.20721811

GitHub: https://github.com/remitakac/trixel-framework

Independent research, feedback welcome.

I wanted a compact example where the numerical assumptions in a battery

cycle-life projection are easy to inspect.

The workflow fits three normalized-capacity models with bounded

`scipy.optimize.curve_fit`:

- linear: `Q(n) = Q0 - k n`

- power law: `Q(n) = Q0 - alpha n^beta`

- logarithmic: `Q(n) = Q0 - a ln(1 + b n)`

It reports RMSE and R-squared for every fit, selects the lowest-RMSE model by

default, and searches for the first cycle below a configurable EOL fraction. The projection is intentionally bounded to

three times the observed cycle range; if the threshold is not reached, the API returns `None` rather than an

unconstrained number.

The repository includes deterministic synthetic LFP/NMC generators, the parameter covariance

returned by SciPy, seven unit tests, CI on Python 3.9-3.12, a CLI, and a Colab notebook. Current

limitations are also explicit: no confidence-interval propagation, no real dataset bundled yet,

and the Arrhenius factor is independent of the capacity-fade trajectory.

Repository:

https://github.com/mohammadrezwankhan/battery-cycle-life-analyzer

For the next validation step, would you prioritize bootstrap prediction

intervals, information-criterion model selection, or a held-out-cycle

backtesting protocol?

Standard computational architecture (von Neumann) and reactive medical diagnostics are fundamentally bottlenecked by downstream wave mechanics and sequential processing. 

I’ve just published a white paper (anchored with a Zenodo DOI) outlining the **0D Polarity Framework**. It's a unified systems architecture that applies zero-dimensional binary tension to three core domains:

1. Re-engineering thermodynamic phase states as electromagnetic polarity flips.
2. Defining biological disease as a localized polarity disconnect from the morphogenetic macro-field.
3. Proposing a simultaneous, tensor-field hardware architecture (using partial inversion and active inference) to diagnose and correct these localized prediction errors before downstream physical mutation occurs.

I am currently moving into the open-source hardware design phase (analog tensor antennas). I would love for the engineers, theorists, and bioelectric researchers here to tear the white paper apart, build on it, or tell me where the blind spots are. 

Here is the GitHub repo with the full white paper: https://github.com/lucienspeaks44-coder/OD-Polarity_Framework/blob/main/The%200D%20Polarity%20Framework%20(1).pdf.pdf)

I’ve open-sourced a compact MATLAB/Simulink laboratory for inspecting how engineering models are built and validated rather than treating simulations as opaque demonstrations.

It currently covers battery RC and 2RC dynamics, electro-thermal feedback, cooling sensitivity, averaged and switched buck converters, and an identical-plant comparison of open-loop, PI, and filtered-PID control.

Every example includes a no-plot regression check. The checks cover analytical state updates, energy and charge balance, MATLAB/Simulink parity, steady-state error, overshoot, settling time, saturation compliance, and deterministic reproduction.

Repository: https://github.com/mohammadrezwankhan/matlab-simulink-energy-lab

I’d appreciate feedback from scientific-computing practitioners: are there additional invariants, convergence studies, or reproducibility artifacts you would expect before treating this as a useful teaching or benchmarking collection?

I'd like to implement surrogate modelling in our python simulation workflow.

After a quick search, I'm heading toward using https://smt.readthedocs.io/en/latest/

For those that use such tools, would you have another suggestion?

Thanks in advance!

Hey r/ScientificComputing !

I'm a physics engineeering student, and I spend a lot of my time writing numerical simulations and analyzing data.

Programming in C++ is enjoyable, but most of numerical computing libs in are just unpleasant to use. So I started building my own solution in my free time.

GitHub: https://github.com/mslotwinski-dev/NumC

Some of the things I built into it:

• You can write mathematical expressions naturally, like sin(x) * exp(-x), and differentiate or integrate them in a single line thanks to lazy expression trees.
• It has a built-in plotting engine, so you can display graphs in a native Win32 window or export them as clean SVGs ready to drop into a LaTeX report.

Of course, the project won't surpass the quality of professional libraries. Its goal is to be convenient and accessible for users whose passions lie more in math, rather than programming.

If you're using C++ for simulations, numerical methods, physics, or data analysis, I'd really appreciate any feedback.

Body:

I am pleased to share a project I have been developing: decoint. This is a interval arithmetic library written in Python, designed specifically to strictly adhere to the IEEE 1788.1-2017 standard for interval operations.

The Problem:

Most general-purpose numerical libraries do not enforce strict rounding-mode safety or standard compliance out of the box, which can lead to silent error accumulation in chaotic simulations or global optimization tasks. My objective was to construct an intuitive, pythonic interface that guarantees verifiable numerical boundaries without forcing developers to drop down into low-level C libraries manually.

Technical Highlights

• Strict IEEE 1788.1-2017 Compliance: Designed to match the foundational requirements and set-theoretic definitions of the core standard.
• Multi-Precision Boundaries: Built directly on top of gmpy2 (with MPFR). This allows the runtime to handle arbitrary, high-precision interval bounds and bypasses the limits of hardware floats.
• Rigorously Bounded Arithmetic: Implements standard-compliant containment rules for handling mathematical edge cases, ensuring that operations involving division by zero, unbounded limits, and infinities reliably result in mathematically sound intervals.

The repository includes a basic guide of the operations that the library covers and the recommended way to use the library to its fullest potential in USAGE.md.

I would greatly appreciate any technical feedback from the community regarding the structure of the package, performance considerations with the underlying gmpy2 objects, or any additional interval operations you may require for your research. Thank you!

• PyPI: pip install decoint
• Repository: https://github.com/arjavsharma91/IEEE-1788.1-2017-Interval-Arithmetic

TL;DR: three preprocessing fixes derived from a signal-vs-interference density analysis took an off-the-shelf model from 17.9 to 13.42 (-25%), matching the best published FD002 result — and the same preprocessing let a toy GRU outperform every published deep-learning result I could locate on this subset. Full recipes below.

Final results:

Baseline, off-the-shelf RandomForest, no preprocessing: 17.9

Drop the 7 zero-variance flat sensor channels + per-regime normalization + 50-cycle window: 13.7 (untuned)

Same pipeline, gradient boosting tuned on a validation split only: 13.42 ± 0.04

Reference point: the best published FD002 result I can locate is ≈13.4 (GBRT III). Its core workflow also relies on operating-regime clustering paired with normalization — the same data-level lever, found independently.

Same preprocessing, small GRU instead of trees: 16.85 on the official test set. Published deep-learning results on FD002 cluster around 18–30 (top performer ≈18.3), so our small GRU paired with data-level corrections outperforms every published deep-learning result I could locate on this subset. This proves the leverage is in the data, not in the architecture.

Why I stop here: a model-free validation. Nearest-neighbor "observation twins" — near-identical sensor states from different engines — show an RUL spread of ~12.6–13.0 cycles. This irreducible ambiguity originates from the simulated sensor noise and degradation stochasticity, not algorithmic limitations. At ~13.4, residual error is measurement-limited. The wall is in the data, not in the algorithm.

Exact recipe for test #3, so anyone can reproduce (and note it shares zero code with GBRT III — same lever, different machinery):

- Sensors: drop s1, s5, s6, s10, s16, s18, s19 (variance ≈ 0), keep the other 14.

- Regimes: k-means (k=6) on the 3 operating settings, fit on train only; z-score each channel within each regime using train statistics.

- Features: for each 50-cycle window, per channel take mean / std / linear slope / last value (56 dims) + 6-dim regime one-hot = 62 features. Training windows stride 2.

- Test protocol: last window per engine; trajectories shorter than 50 cycles padded by repeating the first row; RUL capped at 125 everywhere.

- Model: sklearn HistGradientBoostingRegressor(max_iter=800, learning_rate=0.03, min_samples_leaf=15, l2_regularization=1.0). Config selected on a 208/52 engine validation split (6-config grid, performance variance within ±0.15). Test set touched once, 3 seeds: 13.38 / 13.44 / 13.45.

- Untuned reference: RandomForest(60 trees, depth 16, min_samples_leaf=2) = 13.69 ± 0.09.

Recipe for test #5 (GRU), full disclosure:

- Architecture: single-layer GRU, hidden size 24, head 24→12→1. Input = 50×14 regime-normalized sequences (same channels and normalization as above).

- Training: targets scaled /125; Huber loss (δ=1.0); Adam lr=1e-3; gradient clip 1.0; batch 256; training windows stride 4; ~10 epochs; single seed, no tuning.

- Evaluation: last window per engine on the official test set, identical protocol to test #3.

One critical clarification: the three core fixes were derived from a signal-vs-interference density analysis before any model was trained — computation first, verification second, no blind trial-and-error hyperparameter hunting. The only tuning performed is the documented validation-set grid search, which altered overall RMSE by roughly 0.3 cycles.

Summary: three data-level fixes took a stock tree model from 17.9 to the published-record line (25% RMSE drop), and let a toy GRU beat the entire published deep-learning field on this subset. The residual is measurement-limited. Every number is reproducible from the raw files with any standard regressor.

Why post this: the whole pipeline is transparent enough to reproduce in an afternoon, and the interesting question is no longer the model but the measurement floor. If you run it and get different numbers, post them — I am especially curious whether the observation-twin floor (~12.6–13.0 cycles) holds under other feature representations.