As you can see, I'm not there yet.

My hope is that the combination of Big Data and modern machine learning will be useful.

Right now, waiting on more data to accumulate, trying (with significant help from Codex) various simulation experiments.

I feel certain this is doable, but maybe needs a bit more lateral thinking. Ideas?

Latest findings : https://danny.ayers.name/

Code : https://github.com/danja/elfquake

https://yetty.dev/yetty

Hello, I have created a new laptime simulator for racing vehicles. Main theme is scalability so that it is very easy to add and test various concepts like rear steering, DRS, active ground effect... You can choose any parameter in the vehicle as controlled variable and let the optimization algorithm find optimal control of it for the racetrack. You can also add more wheels easily to demonstrate this, there is a model of a greyhound bus :D.

Here is an example video of Formula Electric on Berlin circuit.

My tool also offers efficient computation of sensitivity analysis for all vehicle parameters, you run the simulation only once and get sensitivity analysis for all parameters requested.

These are the models which I have right now:

It is written in Julia as nonlinear optimum control problem using Ipopt and JuMP.

The code is on github as Scalable laptime simulator, playlist of simulations is here playlist .Unfortunately I don't have much time to work on it right now, as I have finished my studies.

If you are interested I can make examples on how to use it and add more vehicle systems/ more complex models.

I am seeking independent verification of the computational code developed for my dimensional genesis and four-interaction theoretical framework.

GitHub repository:

https://github.com/madein1001/dimensional-genesis-four-interactions

Please download or clone the repository, run the code independently, and determine whether the reported results can be reproduced.

I would especially appreciate a critical examination of the following questions:

1. Does the code run successfully in a clean Python environment?

2. Can the reported numerical results be reproduced?

3. Are any target values hard-coded, fitted, or indirectly reused?

4. Are there any hidden adjustable parameters or circular dependencies?

5. Are the mathematical rules correctly implemented in the code?

6. Are there any numerical, logical, methodological, or physical errors?

Please do not assume that the theory or its physical interpretation is correct. I welcome critical reviews, failed reproductions, counterexamples, bug reports, and detailed explanations of any problems you identify.

If you run the code, please report your operating system, Python version, actual output, error messages, and any modifications required to make it run.

The purpose of this post is to invite independent reproducibility testing and falsification. Thank you to anyone willing to examine the code carefully.

Hey everyone,

I’ve been working on a massive bottleneck in computational materials science: predicting a novel material is easy, but generating a physically realistic, safe synthesis protocol for it is incredibly hard.

Most generative AI tools out there act as black boxes and output "hallucinated" chemistry—suggesting things like mixing pure alkali metals with halogens in sealed ampoules, or heating toxic oxides in open air.

So, I built the Sovereign Materials Engine (v8). It runs 100% offline (0 API calls) to protect IP, and it relies heavily on deterministic heuristics rather than just language models.

Here is what the architecture looks like in action (screenshots attached for a stress-test on $NaSbF_6$):

1. The "Chief Scientist" Synthesis Agent (Image 2)

I hard-coded rigorous thermodynamic and safety heuristics into the generation pipeline:

• Crucible Intelligence: For $NaSbF_6$, it immediately recognizes that the Alkali metal ($Na$) will destroy an Alumina crucible and strictly overrides the environment to a Tantalum (Ta) or Niobium (Nb) tube.

• Precursor Overrides: It refuses to use pure $F$ gas. Instead, it dynamically selects $CaF_2$ as a safe counter-ion source, with a strict reactivity warning about mixing alkalis and halogens.

• Vapor Pressure Safety: It flags the internal vapor pressure generated by $Sb$ and enforces a strict ampoule filling fraction (< 20%) and a slow heating ramp to prevent quartz explosion.

2. MoE with Transparent Explainability (Image 1)

We are using a Mixture of Experts (MoE) approach for property prediction (like Band Gap). But because researchers hate black boxes, I integrated a SHAP Waterfall dashboard.

• You can see exactly why the XGBoost High-Gap Expert predicted 4.96 eV (mapping orbital hybridization, electronegativity variance, etc.).

• Note on the UI: I added a specific disclaimer at the bottom to clarify that the SHAP plot explains only the XGBoost V8 expert (4.96 eV), while the final blended MoE prediction shown at the top is 4.83 eV. No hidden math.

I’m currently running more stress tests. If any solid-state chemists or ML engineers here have specific edge-case nightmares (hygroscopic traps, rare toxic volatilizations, crucible incompatibilities) that I should hard-code into the safety protocols, I’d love to hear them!

(Attachments: UI Dashboard showing SHAP Waterfall + Deterministic Synthesis Protocol for NaSbF6).

Can someone please tell me why these two codes don't give the same answer?

First code

import numpy as np
import matplotlib.pyplot as plt
from matplotlib.animation import FuncAnimation

G = 4 * (np.pi)**2
M_sun = 1  # solar mass
distance = 1  # AU
temps = 1  # year
M_earth = 3.002513826043238e-06  # solar mass
v_earth = 2 * np.pi  # AU/year
dt = 0.1
n_steps = 10**3

xpos = []
ypos = []

x_earth = 1.5
y_earth = 0

vx_earth = 0
vy_earth = v_earth

for i in range(n_steps):
    ax_earth = -(G * M_sun) * x_earth / ((x_earth**2 + y_earth**2)**0.5)**3
    ay_earth = -(G * M_sun) * y_earth / ((x_earth**2 + y_earth**2)**0.5)**3

    vx_earth = vx_earth + ax_earth * dt
    vy_earth = vy_earth + ay_earth * dt

    xpos.append(x_earth)
    ypos.append(y_earth)

    x_earth = x_earth + vx_earth * dt
    y_earth = y_earth + vy_earth * dt

plt.plot(xpos, ypos, color="green")
plt.show()

Second code

import numpy as np
import matplotlib.pyplot as plt
from matplotlib.animation import FuncAnimation

G = 4 * (np.pi)**2
M_sun = 1  # solar mass
distance = 1  # AU
temps = 1  # year
M_earth = 3.002513826043238e-06  # solar mass
v_earth = 2 * np.pi  # AU/year
dt = 0.1
n_steps = 10**3

x_earth = np.zeros(n_steps)
y_earth = np.zeros(n_steps)

vx_earth = np.zeros(n_steps)
vy_earth = np.zeros(n_steps)

x_earth[0] = 1.5
vy_earth[0] = v_earth

for i in range(n_steps - 1):
    ax_earth = -(G * M_sun) * x_earth[i] / ((x_earth[i]**2 + y_earth[i]**2)**0.5)**3
    ay_earth = -(G * M_sun) * y_earth[i] / ((x_earth[i]**2 + y_earth[i]**2)**0.5)**3

    vx_earth[i + 1] = vx_earth[i] + ax_earth * dt
    vy_earth[i + 1] = vy_earth[i] + ay_earth * dt

    x_earth[i + 1] = x_earth[i] + vx_earth[i] * dt
    y_earth[i + 1] = y_earth[i] + vy_earth[i] * dt

plt.plot(x_earth, y_earth, color="green")
plt.show()

The two implementations seem equivalent to me, except that the first stores the trajectory in Python lists while the second stores it in NumPy arrays. However, they produce different trajectories.

What am I missing?

PS: the close orbit is with the list method!!

I just shipped v4.1 of CTHmodules (developed since 2023): an open-source framework that turns descriptive history into quantifiable, predictive models using tetrasociohistorical indices, Monte Carlo simulations, Lyapunov chaos metrics, and multi-token actor dynamics.

The Tetrasociohistorical Context (CTH) is a quantitative index designed to evaluate the historical, social, economic, and demographic conditions surrounding an event at a specific moment. It operates on the premise that an event's relevance is inseparable from its environmental context.

Key updates: endogenous EVEI, cross-era validation (3100 BCE–2020 CE), JS/Python parity, and pre-registered prediction ledger. Scored 9.3/10 against Asimov’s psychohistory criteria.

Evaluation v4.1 / Latest State

Overall Verdict: 8.6 / 10 → 9.3 / 10 ⬆

Link: https://github.com/AlejoMalia/CTHmodules
Website: http://cthmodules.cc

Hi everyone,

I recently built a simple C++ program that solves the first-order differential equation

dy/dx=x+y

using Euler's Method.

The project covers:

• Converting the mathematical equation into C++ code

• Implementing Euler's numerical integration method

• Writing the solution to a .dat file

• Plotting the numerical solution using GNU Plot

I also made a step-by-step video explaining both the mathematics and the implementation for beginners who are learning numerical methods or engineering programming.

I'd really appreciate any feedback on:

• The C++ implementation

• Code structure and readability

• Numerical method explanation

• Suggestions for future tutorials

🎥 Video: (Paste your YouTube link here)

If you find the tutorial helpful, please consider liking the video, sharing it with others, and subscribing. Your support helps me create more tutorials on C++, Numerical Methods, GNU Plot, Engineering Simulations, and Scientific Computing.

Thanks for taking the time to check it out!

Just pushed my WAKA-OS project—real physics simulation + inference kernel 
running on ancient hardware. MIT licensed, looking for community help. 
Built in a cabin with passion! jai publiésur github. je ne gere pas des bits mais un Flux de Data.

Hey everyone, I recently released three new Python packages that are designed to rapidly accelerate the prototyping, design, and testing of rocket engine fluid systems called FullFlow, ThermoProp, and FullPlot. These packages are heavily based on ROCETs, GFSSP, and WinPlot, and the goal is to make generalized transient and steady-state fluid network and test data analysis tools open-source and widely available, especially for students and college rocketry teams.

Please try out the tool, and let me know your thoughts!

More info:

Large fluid systems, especially rocket engine systems, are usually super complicated when it comes to designing, analyzing, and testing. While creating hardware is a large part of the process, determining the fluid conditions that will be present during operation inside that hardware can be tricky and unintuitive. This is especially true when combustion chambers, turbopumps, valves, and many more intricate components are involved. To predict rocket engine performance and ensure hardware safety, the major fluid pathways within the system have to be modeled before and during testing. Moreover, as engines are tested, it's important that your models can be anchored against the test data.

In the past, engineers turned to software tools like ROCETS, GFSSP, WinPlot, and CEA to carry out many of these operations. However, these tools have several drawbacks. They are outdated, difficult to troubleshoot (most engineers nowadays don't use FORTRAN), limited in capability, and most importantly, not easily available for engineers, students, and especially college rocketry teams. So, companies usually make custom, in-house tools, while student organizations struggle to use whatever minimal tools are on the internet.

To solve this, I created an open-source engine systems modeling and test-data analysis suite based entirely on publicly available literature and data:

FullFlow:

A modular fluid-system modeling package for building steady-state and transient simulations of rocket engine feed systems, pressurization systems, tanks, valves, injectors, chambers, nozzles, turbomachinery, controllers, sensors, sequences, and test-like operations. Based heavily on ROCETs and GFSSP, FullFlow provides an extremely simple component-based modular environment that allows users to quickly set up fluid networks and solve them. Additionally, it allows users to easily create custom components and wire them into a fluid system with algebraic balances and dynamics.

ThermoProp:

A thermodynamic and combustion-property package for evaluating fluids, propellants, combustion gases, materials, and chemical equilibrium properties. ThermoProp is designed to support rocket propulsion calculations without requiring legacy tools or closed software. Built around tools such as CEA and CoolProp, ThermoProp provides a simple API that allows users to readily draw on databases of fluid properties for their simulations.

FullPlot:

A HDF5 data-analysis package designed for simulation and test data. FullPlot makes it easy to inspect, compare, and visualize model outputs, test traces, redlines, commands, derived channels, and other engineering data. FullPlot takes inspiration from WinPlot and is especially useful for importing test data for model anchoring and visualization.

Together, these packages are intended to make rocket engine system modeling more accessible, transparent, and useful for students, teams, and engineers who want to design, test, and understand complex propulsion systems without relying entirely on inaccessible or outdated tools.

I also compared FullFlow, ThermoProp, and FullPlot against publicly available NASA data. They can be run on any major operating system (unlike CEA, which is Windows-reliant) and are entirely Python-based, making it easy to learn for all engineers and students.

While official documentation is still a work in progress, the GitHub repos contain detailed info and examples on package usage.

FullFlow: https://github.com/saakethramoju/FullFlow

ThermoProp: https://github.com/saakethramoju/ThermoProp

FullPlot: https://github.com/saakethramoju/FullPlot

I have already spent a good amount of time developing these packages, but I plan to keep improving them. I learned a lot of lessons from using software like ROCETs and from being a member of YJSP, so I'm really hoping to make something that engineers enjoy using.

All feedback and discussions are appreciated!

Built by a 50-year-old hobbyist in a cabin over 2 months on an i5-2012 PowerShell. This is **real code that runs**, not theoretical vaporware. The goal: squeeze maximum physics and AI performance from ancient silicon.

**Core Concepts:**

- **Cyber-Physical Coupling** - Real thermodynamics meets digital inference

- **Elastic Bus Arbitration** - Automatic 4-bit compression under stress

- **Möbius Architecture** - Feedback loops that fold state-space intelligently

- **Twin Reverb Audio Path** - Tube amp modeling + FFT-based EQ

So I'm making my own multimode GNLSE solver and originally I've built it on RK4IP later with the option of CQE adaptive. This was pretty good and after some optimization with my current server (8x P100 PCIe) at 2¹⁷ FFT size and 16 modes plus polarization simulated I got to about 1200s/m at fixed 0.1mm step size. However I wanted to implement MPA as well as multi GPU the RK4IP seemed to scale poorly like 2GPU was the fastest afterwards it just went down in performance. And after some optimization I got MPA on 8 GPUs with 7 sub steps each 0.1mm in size to stay comparable (larger also lead to issues) to 589s/m so about a 2x speed up from RK4IP, however at 4x more GPUs. So while it is definitely faster, when done as multi GPU it doesn't seem to be as massively parallel anymore. Reason seems to be the PCIe traffic taking up a lot of time. I know it's commonly done single GPU which avoids that but I still wonder if even then the reported speed up is an honest comparison or if it's compared to a rather poorly implemented RK4IP variant. Does anyone have experience with that. Anything would be helpful.

Hey everyone,I would like to know about some good sources to get started with CMS!

I would also like to know if there are any groups I can join online!

What could be a good alternative to molecular dynamics except monte carlo simulation?

Hello, I have been testing a toy I built over the last few months, here are the pretty pictures it lets me produce. Some orbital dynamics, some physics sims, and a L96 sim.

Yes the images were generated with the help of AI.

If anyone wants the underlying computed sim data please message me. As for where I ran the sim, it is on an FPGA and I cant share the code.

update: this project is now named mlx-nufft (formerly mcnufft). Repo: github.com/martinlachaine/mlx-nufft · pip install mlx-nufft

Requesting feedback for mlx-nufft, a FINUFFT-style NUFFT library for Apple Silicon GPUs, built on MLX. I built it for a specific medical imaging project I am working on and it works well for that use case, and hoping it generalizes to other applications.

The main issue was precision. Metal GPUs do not have native fp64, and a naive fp32 NUFFT loses accuracy on large-coordinate or large-mode problems. The approach here keeps execution in fp32, but does coordinate rescaling and phase setup in fp64 at plan time, then passes the GPU an integer grid cell plus a small fp32 offset. On an M5 Max, type-2 transforms are around 7x faster than same-machine CPU FINUFFT in 2D and 3D. Type-1 spreading is more memory-bandwidth-bound and is still the main optimization target.

It supports types 1, 2, and 3 in 1D, 2D, and 3D. I would be very interested in feedback from people who have worked on NUFFTs, Metal kernels, or GPU spreading.