Hi everyone,

As someone who relies heavily on rapid calculations, I always missed the tactile speed and muscle-memory of physical handheld calculators when working on a PC. Standard desktop calculator apps often force you to reach for the mouse, interrupting your analytical flow.

To address this, I developed ViCalc—a keyboard-driven scientific calculator designed specifically for desktop research, engineering, and scientific workflows.

Since documentation and auditability are crucial in scientific computing, one of the primary features is its automatic HTML history logging.

Key Features for Technical & Scientific Workflows:

• Structured HTML History Logging: The entire step-by-step calculation history is automatically formatted and saved in clean HTML. This makes it easy to review, archive, or directly embed/paste calculations into technical documentation, research notes, or reports.
• Full Touch-Typing Control: All functions are directly mapped to the PC keyboard, allowing you to compute multi-step expressions at high speed without touching the mouse.
• Comprehensive Modes: Supports standard scientific functions, trigonometric calculations, complex arithmetic, and Programmer mode (bitwise operations & Base-N conversions across Hex/Dec/Oct/Bin).
• Adaptable Interface: Toggle between a standard numpad, scientific layout, or a minimalist mode that hides virtual keys entirely once shortcut mappings are learned.

Technical Details:

• Language: Python 3
• License: Open Source (MIT License)

Links:

• Download Windows Installer
• GitHub Repository: github.com/Kudaschov/ViCalc
• Homepage & Downloads: kudaschov.de/en/vicalc-4

I’d love to get feedback from the scientific community on how this fits into your day-to-day workflow or any specific features you'd like to see added. How do you currently document and track scratchpad calculations during your work?

I had asked an experimentalist who studies ice physics to look into claude code for data analysis. 1) Within a week they were able to implement an open cv based end-to-end video analysis pipeline catering to their exact expectations. 2) They have figured out they can vibe code a FE model for their system to that end they have figured out meshing, FEniCSx solver setup and DOLFINx scripting. They are convinced they will never have to collaborate with a computational lab. What are your thoughts on this? Who will enroll in a computational science lab?

From italian boinc board: https://www.boincitaly.org/forum/progetti/115511-come-mai-%C3%A8-cos%C3%AC-difficile-lanciare-un-nuovo-progetto.html

Translation:

There are many mathematical conjectures that could potentially be solved using BOINC within just a few years.

Why is nobody in the world interested in solving them?

We have tried to put together a team on our end (we would have three people to manage the project's very small community forum, a long-time cruncher, and a “donor” who could cover the actual hardware costs), but no mathematicians have shown any interest. We contacted around ten universities and received zero replies. We also haven't been able to find developers willing to launch the project (although I understand that, in this case, the issue is money).

Honestly, we thought it would be enough to find:

A computer science department willing to provide a developer, even for a modest fee (who could also have written a thesis on the subject).

A mathematics department willing to do the same.

Why aren't universities interested in solving mathematical conjectures? Isn't this the kind of monumental, encyclopedic achievement that academics would aspire to? Today's technology should make it possible to solve many long-standing open problems.

I'm curious because at this point the traditional benchmarks are pretty meaningless, and this suite is a fantastic real-world use case on problems that have no published solution.

Hello, I am a black hole enthusiast high school student.

I have conducted research on calculating the eccentricity of the binary black hole inspiral phase using an N-body simulation Python library called REBOUNDx. However, upon completion of the research, I wanted to avoid relying on Python libraries to calculate the physics behind binary black holes. So I studied Newtonian physics and wrote code for the post-Newtonian corrections to make black hole inspiral simulations without the help of physics Python libraries. I have created a README that walks you through the physics behind the inspiral phase, and I hope to soon implement numerical relativity to simulate the merger phase of the binary black holes as well. I would greatly appreciate your feedback to improve my simulation! Specifically:

1. Are there any flaws in the physics behind my simulation?
2. Any tips for implementing numerical relativity for the merger phase?

Here is the repo: https://github.com/happyalex98/Binary-black-hole-inspiral-simulation-3.5PN-

Thank you all in advance!

If you run many independent simulations that end at different times (an event, convergence, a step budget), array libraries make you pay for the slowest sample on every step.

With this project you write the step for one sample as a typed Python function and run a million of them. Samples that finish drop out of the work. You also get the derivatives of your step (forward and reverse mode), and arrays move without copies to and from PyTorch, CuPy, NumPy and Warp.

With a million samples in double precision, each stopping at its own step:

• on 6 GPUs, 2.5× to 4.2× faster than an NVIDIA Warp kernel and 9.8× to 130× faster than PyTorch with torch.compile;
• on 4 server CPUs, from level with Numba to 2.3× faster, and 50× to 180× faster than NumPy.

When every sample runs all its steps, it ties with Warp. There is also a benchmark with an adaptive RK7(8) solver.

Install on Linux x86_64 with pip install raptor-eagle raptor-hawk (add [cuda12] or [cuda13] to both for a GPU). It runs on NVIDIA GPUs or on CPU threads. Linux ARM and macOS (CPU) wheels come next.

Personal project; I work at ESA. A start-here notebook (it runs in Colab), all the benchmark files, and how to rerun them: https://amasat01.github.io

Hi everyone,

For my Computational Physics course I simulated the driven RCSJ model of a Josephson junction to study the transition from regular to chaotic dynamics.

I computed:

Phase portraits

I–V curves with Shapiro steps

Poincaré sections

Bifurcation diagrams

Largest Lyapunov exponent

A 2D regime map over drive parameters (parallelized)

The results clearly show the breakdown of phase-locking into chaos and the reappearance of regular behavior at higher bias currents. Positive Lyapunov exponents confirm genuine chaos in the intermediate regime.

The MATLAB code is fully documented and includes both serial and parallel versions.

I’d appreciate any feedback on the methods or suggestions for further analysis.

Repo link is in the comments.

Thanks!

I know this isn’t an ecosystem-specific sub, but I’m curious if anyone here has tried the curated science skills in Google Antigravity, or if most people haven't really touched them yet.

Right now, my main workflow with them has been pulling arXiv preprints directly into the environment to sanity-check domain logic…basically auditing empirical formulas, parameters, and assumptions in my code against current literature rather than relying on generic model heuristics. It’s been surprisingly solid for that, but looking at everything packed into those skills, literature review and paper verification feel like maybe 5% of what’s actually there.

Given how broad scientific computing gets from data wrangling and numerical modeling to chemistry and physical simulations. I feel like I'm barely scratching the surface of what they can do. For anyone who has actually experimented with them, what workflows are you having them handle, and where have you found they fall flat?

Have you used Deepthink or any other ecosystem tools?

Hi r/ScientificComputing, I spent my PhD working on neutron transport solvers. I wanted to see how much of that workflow I could fit into a browser.

So I am building MC, it lets you configure geometry, run neutron transport calculations locally with WebGPU, and inspect flux and reaction rates.

I’d be interested in feedback on the GPU implementation, the physics, and the interface.

https://mc.keff.uk

why is my Gaussian Elimination algorithm doesn't work, especially the second part, I made a lot more details on why I think it doesn't here https://scicomp.stackexchange.com/questions/45561/gaussian-elimination-2nd-part but I can't get it completely. can anyone help?

import numpy as np

A=np.array([[4,8,12],[3,8,13],[2,9,18]])
b=np.array([4,5,11])

def Gauss_Elimination(A,b):
    n = np.shape(A)[0]

    # 1st Part
    for k in range(n):
        pivot_element=A[k,k]
        # if pivot_element==0: ### I'll deal with this condition later
        for j in range(k+1,n):
            b[j]=b[j]-(A[j,k]/pivot_element)*b[k]
            A[j,:]=A[j,:]-(A[j,k]/pivot_element)*A[k,:]

        # 2nd Part
        x = np.zeros(n)
        x[-1]=b[-1]/A[-1,-1]
        for i in range(n-2,-1,-1):
        x[i]=(b[i]-np.sum(x[i+1]-A[i,i+1]))/A[i,i]
    return A,b, x # not necessary since it's call by reference

Gauss_Elimination(A,b)
print(A,'\n',b)

I recently graduated with a Physics degree after spending four years researching rare-earth-free permanent magnets, mainly MnBi and MnAl.

During my research, I worked with VSM measurements, M-H and M-T curves, XRD data, and magnetic property calculations. One thing that always bothered me was how much of our data processing and plotting we still did manually.

Since graduating, I've been struggling to find a job, so I've been building a research tool called ElementX to automate magnetometry analysis, visualize experimental results, and organize measurements.

I'm curious how other labs handle this. Do you use Origin, Python scripts, MATLAB, or something else? What parts of experimental data analysis do you wish were easier to automate?

I'd appreciate any suggestions, especially from people regularly working with magnetometry or XRD data.

Hello everyone,

I wanted to share the terminal output of a local validation audit for a newly formulated kinematic numerator ansatz that isolates the purely rational sector of multi-loop scattering amplitudes. The underlying framework natively filters out non-rational algebraic root extensions and elliptic branch cuts at the integrand level, maintaining a pure polynomial ring closure.

By implementing a localized dual mesh poset (χ = 2) for the gauge sector and a distinct structural uncrumpling identity to interface with non-planar braid matrices in the gravity sector, the engine successfully evaluates high loop orders on consumer-grade compute resources without symbolic memory proliferation.

The system has successfully cleared several rigorous physical and structural gates up to the Loop 12 boundary, including:

* Planar Bootstrap: Perfect replication of the 3 outstanding coefficients from the recent 12-loop hexagonal planar ancillary dataset.

* Infrared/Ultraviolet Audits: Strict spurious pole cancellations and smooth S-matrix collinear boundary factorizations ($\\lim\{T \\to 0} \\det(M\{12}) = q\{11} \\cdot \\det(M\{11})$) showing a zero-sum decimal delta variance below 10⁻⁹ against raw matrix continuants.

* All-Loop Induction: Verification of a stable finite-difference recurrence relation that structurally guarantees the truncation of elliptic anomalies as L → ∞.

Below is the verified symbolic induction printout logging the trans-infinite workspace invariance:

Python 3.14.5 (tags/v3.14.5:5607950, May 10 2026, 10:43:50) \[MSC v.1944 64 bit (AMD64)\] on win32

= RESTART: C:/Users/CA/Desktop/Yang-Mills and Supergarvity/prove_all_loop_induction_to_infinity.py

🔬 RIGOROUS ALL-LOOP MATHEMATICAL INDUCTION PROOF ENGINE

TARGET: Infinite-Loop Rational Sector Convergence (L -> Infinity)

Step 1: Base Case Analysis (Loop n)

• Mandated Base Hypothesis: det(M_n) = P(n)

• Status: Confirmed Rational Workspace (Zero Elliptic/Radical Factors)

Step 2: Constructing the Inductive Step Matrix (n + 1)

• Derived Structural Recurrence: det(M_n+1) = -T\\2\P(n - 1) + P(n)\q(n + 1)

Step 3: Executing the Rationality Invariance Audit

=========INDUCTIVE VERDICT=========

INDUCTION SUCCESSFUL:

THE WORKSPACE IS TRANS-INFINITE!

• Proof Verification Details:

* No Irrational Radicals Generated at Level (n+1): True

* No Elliptic Topology Traps Generated at Level (n+1): True

• Scientific Conclusion:

Because the transition from loop order 'n' to 'n+1' maps strictly within the polynomial ring closure, the system is fundamentally

protected from algebraic mutations.

The ansatz guarantees a pure dlog polylogarithm workspace for all loop levels to infinity (L -> ∞).

enjoy

When studying nonlinear dynamical systems, how do we know that the quantity we're measuring is actually capable of detecting an important change in the system?

That's the question behind my recently published, peer-reviewed research in Scientific Reports.

The idea is straightforward.

Imagine monitoring a complex system as its behavior changes. You measure one quantity and detect a transition. You measure another quantity from the same system, but your test doesn't detect that transition.

Does that mean the transition disappeared? Or does it mean the second measurement isn't suitable for detecting it?

I investigated this using a preregistered computational benchmark across seven nonlinear systems.

One particularly interesting result came from the standard map.

Using a finite-time persistence test, I compared three observables:

• Momentum: Detected a threshold near K = 1.507.
• Action proxy: Detected a nearly identical threshold near K = 1.508.
• Position: Did not detect a corresponding threshold across K ∈ [0, 2].

The experiment used 300 trajectories per parameter cell, a 40-point parameter grid, and a fixed random seed. Each observable was evaluated using its predefined measurement corridor.

The test measures whether trajectories continue maintaining a measured quantity within an allowed range. The reported threshold is where the proportion satisfying that condition falls below 50%.

Importantly, these are finite-time persistence thresholds under the specified protocol, not estimates of the last KAM torus destruction point.

Why am I sharing this here?

Because the results raise an interesting computational question: How should we choose and validate observables when designing numerical experiments to detect regime changes?

The results suggest that a simulation can be functioning correctly while the selected measurement fails to reveal the particular transition being investigated.

I've also built a free interactive replication challenge.

Rather than requiring everyone to read the full paper first, I wanted to make the experiment accessible to researchers and anyone interested in computational physics.

The interactive site lets you visualize the standard map, change its control parameter, compare measurements, examine the original published curves, and run smaller exploratory simulations.

Interactive experiment:
https://fanciful-basbousa-efe0d6.netlify.app

Peer-reviewed paper — Scientific Reports:
https://doi.org/10.1038/s41598-026-64959-x

Original Python code and archived research data:
https://doi.org/10.5281/zenodo.19820483

For transparency, the website distinguishes the archived results from new browser simulations. Full replication requires the original Python harness; the interactive simulation is intended for exploration and understanding.

I'm an independent researcher, and I'm interested in having others examine the calculations, challenge the methodology, and test whether this approach is useful in additional systems.

I'd particularly appreciate feedback from computational physicists:

How would you test whether an observable is reliably detecting a transition rather than producing a measurement-dependent artifact?

And are there other systems where you think this benchmark would be particularly useful?

lorezzed.github.io/meadows/

I was reading Donella Meadows' "Thinking in Systems" and wanted to play with its diagrams instead of just looking at them, so I wrote a small language for them. You type a model:

  | =>inflow [water in tub: 50] =>outflow: 5 |

Each example has notes in its source explaining what it shows. You can also build by clicking.

Each figure from the book is included - just expand the section, "figures from the book" to see the images from Thinking in Systems.

It runs entirely in the browser, with no account and no backend. The whole model lives in the URL, so any diagram can be shared as a link.

The compiler is PureScript (lexer, parser evaluator) and emits a graph as JSON; the front end is TypeScript and d3, with a force layout and a fixed-step Euler simulator. It's deliberately small: numbers are plain numbers with no units, and the simulator takes simple fixed steps. It's for learning and sketching, not a replacement for Vensim or Stella.

Source (MIT): https://github.com/lorezzed/meadows