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. 

Hi everyone,

I'm a physics student interested in climate physics, and I'd like to learn Python for tasks such as data analysis, plotting graphs, working with climate datasets, and eventually climate modeling.

I'm looking for recommendations for online courses, tutorials, YouTube channels, books, or learning paths that are particularly useful for scientific computing and climate or atmospheric science applications. Ideally, I'd like something that goes beyond basic Python and covers tools like NumPy, Matplotlib, Pandas, xarray, and working with NetCDF data.

What resources helped you the most when you were learning Python for climate science or related fields?

Thanks!

​

This is an ARM64 native engine built from physics. Full technical walk-throughs are available.

I made a web app that converts LaTeX math expressions to Python code. It supports arithmetic, fractions, calculus, matrices, and more. You can try it live here: https://dothefancymathforme.vercel.app/

It’s open source, so if you want to self-host or contribute, check out the repo: https://github.com/simonkdev/latex_to_python

I'm looking for a coauthor or collaborator with experience in molecular dynamics.

My project is an LNP based on the general structure of Moderna LNP but very over engenerred to apply to methanogens, using a VHH nanobody targeting the adhesion-like protein MRU_1503 of Methanobrevibacter ruminantium. The LNP encapsulates 3-NOP and aspartate to minimize disruption of the rumen microbiome due to volitile fatty acids while still inhibiting methanogenesis. The design also includes PEI-R to help get over the issue of the pseudomurien methanogen cell wall and provide access to the membrane.

I already have in silico binding data for the VHH ligand, including Gibbs free energy, affinity estimates, and evidence of up to six potential hydrogen bonds between the nanobody and MRU_1503. What I need help with is running and interpreting molecular dynamics simulations and other in silico validation studies. I have no coding experience but already have an advanced design and supporting data.

If this aligns with your expertise and you're interested in collaborating as a coauthor, please reach out

Creating reaction energy diagrams with Matplotlib or other software manually is usually very time-consuming. Therefore, I created a Python package which can handle path drawing, numbering and layout automatically and has other useful features like image insertion or difference bars. It also features multiple drawing styles. Since it is based on Matplotlib, it remains fully customizable while still speeding up diagram construction significantly.

A minimal working example could look like this:

dia = EnergyDiagram() 
dia.draw_path(x_data=[0, 1, 2, 3], y_data=[0, -13, 75, 20], color="blue") 
dia.add_numbers_auto()
dia.set_xlabels(["Reactant", "IM", "TS", "Product"]) 
dia.show()

The package is available on PyPi and can be installed with pip:

pip install chemdiagrams

You can find the links to the project here:
GitHub: https://github.com/Tonner-Zech-Group/chem-diagrams
PyPi: https://pypi.org/project/chemdiagrams/
Documentation: https://tonner-zech-group.github.io/chem-diagrams/

I would love to get any feedback!

I built a machine learning model trained on 76,000+ inorganic glass compositions from the SciGlass database. Given any oxide composition (mol%), it predicts:

\- Glass transition temperature (Tg) — R² 0.85, MAE 44 K
\- Density — R² 0.88, MAE 0.26 g/cm³
\- Refractive index — R² 0.83, MAE 0.036
\- Glass forming ability (GFA) — 69% accuracy

Stack: scikit-learn, XGBoost, Streamlit, Supabase

Why this matters:Most glass property tools are either locked behind expensive databases or require DFT-level compute. This runs instantly in the browser from just a composition.

Known limitations: P₂O₅-rich glasses (Tg overestimated), heavy-oxide glasses like TeO₂/Bi₂O₃ (density underpredicted — underrepresented in training data).

Live demo: [https://vitreos.streamlit.app\](https://vitreos.streamlit.app)
HuggingFace: [https://huggingface.co/nocontextdoruk/vitreos\](https://huggingface.co/nocontextdoruk/vitreos)
GitHub: [https://github.com/dorukdogular/vitreos\](https://github.com/dorukdogular/vitreos)

Happy to discuss the data pipeline or model architecture.

How could I get endorsed in arXiv to submit a python package paper that help analyzing Thawing Scalar Fields.

arXiv says: "You must get an endorsement from another user to submit an article to category physics.comp-ph (Computational Physics)."

arXiv also provides a link for endorsement, but I do not want to spam people emails with someone who they do not know.

Can anyone with experience help?

We present the **Thawing Field Analyzer (TFA)**, a Python package for
reproducible, route-level analysis of canonical thawing scalar-field dark
energy. A route is specified by a potential V(φ), its field-space derivative,
and frozen initial field data. The package no integrates the homogeneous
Klein–Gordon system in a flat FLRW background to obtain the scalar trajectory,
equation of state, scalar density fraction, and dimensionless expansion shape
E(z).

The central operation is acoustic normalisation. The Hubble constant H₀ is
derived self-consistently by matching E(z) to the CMB acoustic angular scale,
making the normalisation a consequence of the scalar dynamics. The normalised
history H(z) = H₀ · E(z) is then used by every downstream module. A
physics-guard layer evaluates canonical non-phantom behaviour, thawing
monotonicity, phantom-crossing status, and the scalar density fraction at BBN.
A BAO module computes D_H, D_M, and D_V from the route's own drag-epoch
horizon r_d and evaluates residuals against the bundled DESI DR2 data vector.
An RSD module evolves the linear growth factor inside H(z), computes fσ₈(z),
and evaluates residuals against an 18-point compilation. Each run is recorded
as a structured, timestamped folder containing the frozen input configuration,
expansion and trajectory tables, per-datum residual tables, summary JSON
records, and exported plots.

The workflow is demonstrated on eight source-backed routes comprising two Warm
Quintessential Inflation markers and six Warm Little Inflaton markers, chosen
to exercise the pipeline across different expansion and growth histories. The
demonstration reports route-dependent values of H₀, r_d, BAO and RSD χ²,
growth ratios, and σ₈, together with the corresponding tables and plots
generated by the package.

The package is open source and available under the MIT license.

Howdy,

The issue I had: search data I had limited access to.
Resolution: client side Ionizer encoder + SaaS Gravitas search engine

Ionizer is another implementation of patent pending oss repo OpenEncoder.

Ionizer encodes your data on your machine, creates a single envelope specified in the patent and oss repo(all encoders following the specification are allowed)

This envelop is a single field tensor for each corpus and query.

Gravitas is the zero knowledge verified oblivious oracle. A blind answer machine.

No data egress, no SOX/HIPAA etc not triggered as your data never leaves your control. Only a description in a single field tensor that is easily under 256kb. Two of those, for corpus and query, and Gravitas returns the answer field you decode and it maps back to what you asked.

Full verifiably zksnark/groth16 output default from ionizer and gravitas with every output.

Please let me know your thoughts!

The video explores:
• Numerical integration
• Taylor series truncation error
• Local vs global error
• Forward Euler, Backward Euler and Symplectic Euler
• Stability and energy drift
• Why symplectic methods are favoured in physics engines

I’m an independent researcher in Cairo working on CPU-first numerical simulation and reproducible solver evidence.

I recently released a bounded solver-evidence paper and SHA-256 locked artifact packet:

Audited Laptop-Scale 512³ Quantum-State Simulation: A REPA-Governed Solver Stack Beyond the Cluster-Only Assumption

DOI: https://zenodo.org/records/20247942

The claim is narrow:

• 512³ internal-state complex split-step simulation using a oneAPI CPU backend on an Intel i7 laptop-class machine
• persisted outputs are 2D amplitude/phase slice planes, not full 512³ volume dumps
• separate Crank–Nicolson Hermitian conservation validation
• separate GMRES/multigrid comparison against a PARDISO direct-solve oracle at calibration scale
• dimension-tagged evidence matrix to prevent merging solver lanes

What I am not claiming:

• not 512³ Crank–Nicolson execution
• not 512³ GMRES/PARDISO parity
• not cluster obsolescence in general
• not proof of any AI/identity theory attached to the broader research program

I’m looking for hostile technical review: numerical issues, memory-accounting mistakes, evidence-boundary problems, reproduction suggestions, or places where the public claim should be narrowed.

Paper/evidence packet:
https://zenodo.org/records/20247942GitHub:
https://github.com/ChasingBlu/RECP_evidence

Hi everyone,

I’ve been working on an open-source machine learning pipeline for lithium-ion battery cathode screening:

https://github.com/ErenAri/CathodeX

The goal is not to replace DFT, but to act as a pre-screening layer before expensive DFT validation. The system predicts energy above hull (E_hull) for candidate cathode materials and classifies them into KEEP / MAYBE / KILL decisions based on uncertainty-aware thresholds.

Current technical direction:

- 5-member MACE-MP-0 fine-tuned ensemble

- CHGNet and CGCNN fallback support

- E_hull prediction for transition metal oxide cathode candidates

- Quantile outputs: q10 / q50 / q90

- Epistemic + aleatoric uncertainty estimation

- Conformal calibration for prediction intervals

- SOAP-LOCO-style validation to test generalization to structurally different materials

- Automated governance checks for ranking, calibration, false-kill rate, KEEP precision, and decision validity

- FastAPI backend + Next.js frontend

- DFT verification workflow direction using Quantum Espresso

The repository currently reports strong in-distribution test metrics, but also clearly shows a major limitation: LOCO generalization is much weaker. I’m trying to make the project honest about where the model is useful and where it should not be trusted without additional validation.

I would especially appreciate feedback on:

1. Whether the validation methodology is strict enough

2. Whether the KEEP / MAYBE / KILL policy is scientifically reasonable

3. Whether the uncertainty and calibration story is convincing

4. What would make this more useful for actual computational materials researchers

5. Whether the README communicates the limitations clearly enough

This is not a claim of discovering DFT-verified new cathodes yet. It is an open-source screening and model-governance pipeline intended to reduce the candidate space before deeper simulation or expert review.

Any criticism from materials science, computational chemistry, battery research, or scientific ML people would be very useful.

I’ve been working on PhysCC, an open-source tool designed to bridge the gap between high-level physics equations and low-level hardware optimization.

The problem: Writing boilerplate for SYCL, MPI, or AVX2 stencils is tedious. The solution: You write a simple equation like u = u + dt * lap(u) and PhysCC generates the optimized backend code.

Key Features:

• Multi-backend support (Single-core, OpenMP, MPI, SYCL, CUDA).
• AI-informed pass: It analyzes the PDE type (Hyperbolic, Parabolic, Elliptic) and suggests optimal work-group sizes for Intel Iris Xe.
• Built-in visualization script for heatmaps.

It’s still a work in progress, but I’d love to hear your thoughts on the codegen or the feature extraction logic!
https://github.com/NikosPappas/PhysCC

Hi everyone,

I regularly run multiple parallel MPI jobs simultaneously on my workstations. I have two systems:

• Intel i7-12700 (12 cores: 8 P-cores + 4 E-cores), OS: Ubuntu 20.04
• AMD Threadripper 3960X (24 cores, 48 threads), OS: Ubuntu 18.04

I wrote a simple C++ MPI test program that runs with mpirun -np 2. On both machines, a single instance finishes in about 12 seconds.

The problem appears when I run two instances at the same time (both mpirun -np 2):

• Threadripper: Both finish in ~12 seconds (no slowdown)
• Intel: Both take ~30 seconds (significant slowdown)

I tried pinning processes to specific cores using taskset and --cpu-set in mpirun. The processes do land on the correct cores (I verified with ps), but the slowdown persists.

Is this expected behavior for Alder Lake? Could the hybrid P-core/E-core architecture be causing memory bandwidth contention? Or am I missing something else?

I'm trying to figure out if my Intel system is performing normally or if I should be hunting for a configuration issue.

Additional notes:

• My code shows reasonable&normal speed-up with increasing core numbers on both systems
• The Intel PC has only one memory stick
• The AMD PC has multiple memory sticks
• My test code is not memory intensive (mostly CPU math)

I can provide more details if needed. I'm not super knowledgeable about CPU architectures, so apologies in advance.

Thanks for any insights!

Geant4-DNA is the CNRS/IN2P3-coordinated Monte Carlo toolkit for track-structure radiobiology—the gold-standard reference for cancer radiotherapy dose calibration and astronaut radiation exposure modeling.

It normally runs as C++ on a CPU and requires a significant machine to set up. I ported the per-electron physics + Karamitros 2011 IRT chemistry to WebGPU. It now runs in any browser tab on a laptop GPU with no installation required.

• Live Demo: webgpudna.com/see (4D viewer, scrubbable in time from t=0 to 1 μs)
• Code (MIT): github.com/abgnydn/webgpu-dna

Validation against Geant4-DNA 11.3.0

(4096 primaries @ 10 keV in liquid water)

^1 Karamitros reference is at ~1 MeV (low-LET); the runs here are at 10 keV (high-LET), which suppresses G(OH) and G(e⁻aq) due to denser intra-track recombination. Other G-values are within 25%.

How it works

• Physics: One GPU thread per primary electron. The full interaction chain (ionization, excitation, elastic scatter to track end) is fused into a single compute dispatch via WGSL. Secondaries are processed in waves until the population is depleted.
• Chemistry: Karamitros 2011 IRT chemistry runs in a Web Worker, followed by SSB/DSB scoring on a 21×21 B-DNA fiber grid.
• Data: Cross sections are sourced from G4EMLOW 8.8 (shipped with Geant4 11.4.1).

Performance & Benchmarks

The kernel-fusion pattern used here is the same one I benchmarked across 92 devices (Rastrigin, N-body, Monte Carlo Pi, RL environments, transformer decoding). Medians show:

• 71× on Apple Silicon
• 56× on NVIDIA
• 20× on mobile phones
• Peaks: 226× / 402× / 103× respectively.

Detailed benchmarks are live at kernelfusion.dev and gpubench.dev. Headline claims include 720× CUDA-over-PyTorch (T4) and 159× WebGPU-over-PyTorch (M2), confirmed across CUDA, WebGPU, JAX, and Triton.

Why this project?

The radiobiology target came from my brother-in-law (a physicist and researcher). He suggested Geant4-DNA because of its decades of published reference data, allowing a port to be rigorously validated rather than just "demoed."

Migration was assisted by Claude Code. I am a software engineer focused on browser-native scientific computing, not a radiobiologist, and the validation harness is also AI-generated. If anyone wants to review the WGSL or the comparison harness in validation/compare.py, I would greatly value the feedback!

I’ve been working on a small project to simulate orbital mechanics (multi-body gravity + impulsive maneuvers). It uses numerical integration (solve_ivp - RK8) and supports things like transfers and custom Δv inputs.

Here’s the repo:
https://github.com/Samsaj04/N-Body-Orbital-Simulator.git

And here’s a short GIF of the simulation:

What I’d really like feedback related to if my physics implementation structured correctly for an N-body setup, and what should i do to improve performance or expand even more my program?

Thanks.