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?

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

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!!

I’ve just published an open-source Python validation suite and interactive toolkit centered around the Warped Information Number (WIN) Paradigm a framework that models physical reality and spacetime as a discrete Majorana QIN substrate rather than a continuous manifold. https://github.com/007STAN/WIN-PARADIGM-VALIDATION

Cosmic Expansion Dispersion Engine (Hubble Tension): Computes how microcanonical substrate dispersion across discrete sector boundaries naturally bridges early-universe CMB baselines (67.4 km/s/Mpc) with local distance-ladder measurements (∼73 km/s/Mpc)

Substrate Energy Cascade Engine (Navier-Stokes): Derives the Kolmogorov −5/3 inertial range and multifractal intermittency corrections from network sector-switching rates without adjustable eddy viscosity.

Lepton-Substrate Polarization Engine (Proton Radius Puzzle): Models mass-dependent vacuum polarization screening depths to bridge electronic and muonic hydrogen charge radius shifts.

Quantum Substrate Flicker Engine (1/f Noise): Computes macrographic pink noise spectra and parameter-free Hooge-equivalent parameters (αH​≈3.68×10−3).

Glassy Freezing & Kauzmann Entropy Engine: Resolves the Kauzmann entropy catastrophe and computes parameter-free heat capacity jump ratios (ΔCp​) at Tg​ via finite-N Wishart variance suppression.High-Energy Subsystems: 

Additional modules covering the Higgs mass (126.09 GeV), NA64 dark photon limits, and black hole Page curves.

• GitHub Repository: https://github.com/007STAN/WIN-PARADIGM-VALIDATION
• Releases: Check out the v1.0.0 release tag for the packaged codebase.

Over the next year, I want to develop practical programming and computational skills that I can use to explore physics, CAD, simulations, animation, and higher-level mathematics such as topology. Rather than trying to learn every software package individually, I want to understand the underlying principles that transfer across programming languages and platforms—such as abstraction, data structures, algorithms, numerical methods, visualization, modeling, and modular software design.
I also want to learn how to use AI intelligently as part of my workflow without allowing it to replace my own understanding. My goal is to use AI for explanation, brainstorming, debugging, research assistance, and exploring alternative approaches while still doing the important mathematical reasoning, computational experiments, and scientific interpretation myself.
As part of this process, I want to become familiar with tools for symbolic mathematics, mathematical typesetting, technical writing, simulations, visualization, and CAD. I am particularly interested in tools that allow me to work with symbolic equations and produce mathematical documents in the spirit of LaTeX.

The Problem

We live in an era of information abundance, but also of fragmentation. Your data is in binary files. Your analyses are in Jupyter notebooks. Your figures are in a directory. Your bibliography is in a reference manager. Your code is in Git. Each piece is isolated. Reproducing results? Good luck.

Current tools solve this partially: Git for code, Dropbox for files, paper notes for parameters. But there is no common thread tying everything together.

Enter OSV: Open Sapientia Vault

OSV: Forge, Track, Preserve.

OSV is an open, extensible platform that helps you create, organize, transform, preserve, and share knowledge of any kind – scientific, technical, artistic, or humanistic – regardless of data format or tools used.

Core Concepts (Simple)

· Project: The container for all your work. A directory with data, results, config, and provenance.

· Workspace: A set of related capabilities (e.g., Signal Processing with FFT, filtering, PSD).

· Plugin: An adapter connecting OSV to external tools (MATLAB, Python, ObsPy, etc.).

· Artifact: Any file – text, image, seismic signal, audio, database – with a unique hash (digital fingerprint).

· Provenance: Automatic logging of who did what, when, with what parameters and inputs.

· Versioning: Hybrid – Git for text, git-annex for large files, BorgBackup for encrypted backups.

How It Works (Practical Example)

You're a scientist studying Apollo mission seismic data. You have miniSEED files. You want FFT.

1. Create a project.

2. Import .mseed files.

3. Select a Signal Processing workspace with fft capability.

4. Assign MATLAB or Python to handle fft.

5. Run the operation with parameters (e.g., window size 4096).

6. OSV invokes the tool, collects results (spectrum + figure), saves them.

7. Everything is recorded: file, parameters, tool version, who, when.

8. Check provenance anytime.

9. Trigger backup locally or to the cloud.

10. Export and share the entire project with a colleague.

You focus on the science. OSV handles the logistics.

Benefits

· Reproducibility: Always recreate exactly what you did.

· Clear Attribution: Every operation is tied to an author and timestamp.

· Flexibility: Change tools without rewriting workflows – just change the plugin.

· Tool Agnostic: Use MATLAB, Python, ObsPy, Photoshop – integrate, don't replace.

· Any File Type: Text, images, audio, signals, databases – all treated equally.

· Long-term Preservation: Automatic backups and robust versioning.

· Simple Collaboration: Share complete projects with history and provenance.

Concrete Example: Apollo Seismic Project

The demo project includes:

· Signal Processing: FFT, filtering, PSD, spectrograms.

· Seismology: arrival detection.

· Instrumentation: calibration, instrument response.

· Visualization: waveform plots, spectrograms.

Each capability is declared in the workspace. The project defines which tools to use (MATLAB for FFT, ObsPy for arrival detection). Data is imported as artifacts. Results are recorded with full provenance.

Towards a Knowledge Community

OSV is not just software. It's a philosophy of collaborative, open work. A public repository of workspaces, plugins, and projects is envisioned – like CTAN for LaTeX or PyPI for Python.

Join the OSV Movement

This is ambitious. I can't build it alone.

I'm seeking volunteer developers.

· Python experts

· Systems architects

· Documentation writers

· Testers

The project will be released under a Free, open, accessible license.

Current Status

The public repository hasn't been started yet. We're in the architectural definition phase. First code will be pushed once this foundational document is complete.

Goal: Version 1.0 ready in 2027.

How to Get Involved

Email me to express interest, share your skills, or ask questions.

Contact: arcilagiraldooscaralejandro@gmail.com

During the process of building a system simulator I collected a bunch of ODE solver coefficients and put then now into a library. Including relevant metrics (A-stability, stiff accuracy, convergence order, cost, etc.). Besides being a handy overview of the methods out there, I also think it looks cool.

You can browse through it here: solvers.milanrother.com

And visit it on GitHub here: github.com/milanofthe/solvers

I've spent a few years working around HPC, and in my experience I rarely saw people using things like Nextflow or Snakemake. It was mostly scripts, bash, Slurm jobs, notebooks, custom stuff, etc.

But then I look around online and it seems like everyone is using workflow engines.

Do you use Nextflow, Snakemake, etc.? Or they only work for the "curated workflow library" those have?

Hello r/ScientificComputing community,

In the past month, I have been working on creating a simulation software from scratch. The idea came to me when I was working a on a few projects that, when I looked at the math, essentially required me to solve the same kind of problems. The equation looks like the following, and it's generally referred to as generic networked dynamical system equation.

ẋᵢ = Σⱼ fᵢⱼ(xᵢ, xⱼ) + sᵢ(xᵢ, u)

Essentially, this is a graph equation. i is a node, xᵢ is a vector of states in a node, fᵢⱼ(xᵢ, xⱼ) is an edge connect nodes i to j, and sᵢ(xᵢ, u) is a source term where you can hook up an input or define a function at a node that affects itself.

I discussed this idea with a few friends before going ahead to implement; it went over the head for some, while others thought it would be interesting to see. There are applications for this in robotics, power grids, heat exchange, etc. And, the idea is inherently interdisciplinary; the node states can be from cross-domains and edges too. We can simulate a motor and it's kinematics; the motor may get heated up due to resistances, and the air pocket near it may get heated up while trying to cool it down... A real cross-domain simulation could be done with this kind of a setup.

The following is the link to the GitHub page. It's licensed under MPL 2.0.

https://github.com/zenineasa/Konjugate

I would love to hear your thoughts about this. Bug reports, workflow issues, new ideas to build on top of it... I look forward to hearing it all.

https://github.com/forloop11/markdown-cornell-notes

A LaTeX and Markdown build pipeline that generates printable Cornell style note pages for meetings. Each page carries a header with topic, date, attendees, and time, a large notes panel with a cue column beside it, and a summary band below, all left blank for handwriting on the printout.

Header fields live in YAML and note content lives in Markdown, so the LaTeX template itself never needs hand editing. Python generator scripts convert both into TeX fragments, pandoc handles the Markdown to LaTeX conversion, and a single make command produces a PDF named automatically from the topic, date, and location fields. Content is measured and paginated automatically, with optional directives for forcing page breaks and for routing text into the cue column or summary band of a specific page.

The project also includes a Streamlit editor app that places the header form, a CodeMirror Markdown editor, and a live PDF preview side by side in the browser. The editor adds a formatting toolbar, slash command snippets, and autocomplete for asset paths and code fence languages. Its JavaScript bundle is vendored rather than loaded from a CDN so the app works offline, and it relies on native browser spellcheck rather than any app side state.

Built with Python, LaTeX, pandoc, Streamlit, CodeMirror, JavaScript, and Make. Released under the MIT license.

Open4D is an early research-software project for experiments on 3D geometry that changes over time. The current shared layer focuses on making codec and reconstruction experiments comparable rather than presenting a product launch.

The lightweight core provides:

- a finite `Sequence[Frame[TriangleMesh]]` model with timestamps and topology declarations;

- lazy OBJ/PLY frame-folder loading and manifested directories;

- headless `--info` validation for frame counts, duration, topology, and bounds;

- a common viewer and OpenUSD packer;

- a reference-versus-decoded comparison tool.

The comparison deliberately does not assume identical connectivity. It measures decoded→reference and reference→decoded nearest-neighbour distances, supports point-to-point and MPEG-style point-to-plane definitions, and reports the worse direction as the symmetric result. A fixed reference bounding-box diagonal is used as the PSNR peak, and a fixed sequence-wide colour scale avoids making per-frame errors visually incomparable. CSV output is available for downstream analysis.

The repository also documents the minimum record expected for performance claims: exact revision, configuration, dataset/frame range, encoded byte count, runtime environment, and metric implementation.

Repository: https://github.com/open4dfoundation/Open4D

Status disclosure: the project-authored Python core is MIT-licensed and usable from source. Historical codec snapshots, datasets, media, and native integrations in the same research tree still have unresolved third-party provenance, so the full repository is not release-ready. I would value feedback on the shared abstractions and whether the comparison metrics are sufficient for cross-codec experiments.

I wanted to understand what’s going on with Shors algorithm without getting lost in the quantum stuff. This is public on Github if you want it

https://github.com/Byt-wyze-technology/QuasiShor

Or if you just want to mash buttons and see what it does the app is hosted
https://quasishor.byt-wyze.com/

The idea is that you dont need to know anything about it, you can click buttons and see whats going on in a visual way without needing to know anything about quantum beforehand.

Hope it helps someone else too.

HI! I am applying for internships and many do not the option to manually write what my major is, but instead have a drop down option. What should I choose? I most often choose computer science but as yall know that is not the most accurate description.

Thanks!!

Hi,

I made PRIK, a tool that generates native Python extensions from Fortran and C code.

pip install prik
python3 -m prik my_module.f90 --out my_module

The interesting part: it creates an editable .pyi contract so you can reshape the Python API (rename things, turn procedures into methods, hide arguments, change return values, etc.) without modifying the original Fortran.Supports modules, derived types (as classes), arrays, strings, allocatables, pointers, callbacks, and more.Already tested on real libraries: BLAS, LAPACK, FFTPACK, MINPACK, BSPLINE-FORTRAN.Still alpha. Fortran support is much more mature than C.

• Docs: https://pynumlab.github.io/prik/
• GitHub: https://github.com/PyNumLab/prik

Feedback is welcome!

I built a math parser (uCalc), and I wanted to share a practical example of how to use its architecture to solve custom scientific problems.

If you build scientific models, simulations, DSLs, etc., you will need to evaluate math expressions defined at runtime. While standard math parsers might let you define custom functions, they may not let you use the exact syntax you want, and your functions might not be able to implement certain iterative algorithms straightforwardly.

To get around this, I designed the engine to allow callbacks that can receive arguments passed by expression. I also make use of the Transformer to allow for more flexible syntax. Here is an example of a custom EqSolve function built using the Bisection Method algorithm.

using uCalcSoftware;
var uc = new uCalc();

static void EqSolveCb(uCalc.Callback cb) { // Callback based on the Bisection Method
   var expr = cb.ArgExpr(1);     // ByExpr: Unevaluated Expression object (lazy evaluation)
   var a = cb.Arg(2);            // Argument 2: Range Minimum
   var b = cb.Arg(3);            // Argument 3: Range Maximum
   var variable = cb.ArgItem(4); // ByHandle: The variable Item object

   // Helper to update the variable in the uCalc engine and evaluate the expression
   double EvaluateAt(double val) {
      variable.Value(val);   // Push the new test value to the variable
      return expr.Evaluate(); // Evaluate the pre-parsed expression
   }

   // Ensure f(a) < f(b) so we always know which direction to slide the bounds; swap a & b if necessary
   if (EvaluateAt(b) < EvaluateAt(a)) (a, b) = (b, a);

   var midpoint = 0.0;
   var fMidpoint = 0.0;

   // Bisection loop
   for (int i = 0; i <= 100; i++) {
      midpoint = (a + b) / 2;
      fMidpoint = EvaluateAt(midpoint);

      if (Math.Abs(fMidpoint) < 1e-7) break; // Stop if close enough to 0

      // Narrow the bounds (compact logic!)
      if (fMidpoint < 0) a = midpoint; else b = midpoint;
   }

   if (Math.Abs(fMidpoint) > 1e-5) cb.Error.Raise("No solution found in the given range.");
   cb.Return(Math.Round(midpoint, 7)); // Return the final solved value
}

// 1. Define variables that might be used by the end-user
uc.DefineVariable("x");
uc.DefineVariable("MyVar");

// 2. Transformer converts EqSolve(L = R) into EqSolve(L - (R))
var t = uc.ExpressionTransformer;
t.FromTo("EqSolve({L} = {R} [[,]for {var}][, {min}, {max}])",
"EqSolve({L} - ({R}), {min}{!min:-10000}, {max}{!max: 10000}, {var}{!var: x})");

// 3. Define the custom function signature
uc.DefineFunction("EqSolve(ByExpr eq, min, max, ByHandle variable)", EqSolveCb);

You can test this exact equation solver code interactively in your browser here:

https://www.ucalc.com/

I'd love to hear how this community handles runtime formula parsing in your own simulators and DSLs, or if you have any questions about the engine's architecture!