https://reddit.com/link/1v4ktsx/video/kndar885m0fh1/player
You can paste SMILES strings into the structure editor or draw your own structures — both get name
Web app: openclatura.org
Hi everyone,
I’ve been working as an independent researcher on an alternative regularized framework for the 3D incompressible Navier-Stokes equations, focusing on mitigating high-energy convective blow-ups while structurally enforcing global energy conservation laws.
Instead of using traditional subgrid models or smoothing techniques, I introduced a modified convective operator T\_reg(u) based on a strictly anti-symmetrized tensor architecture, embedded with a high-gradient dynamic attenuation factor Gamma(u). By definition, this guarantees that the energy inner product strictly equals zero unconditionally, preserving the structural L2 stability bound.
To back the analytical proof, I wrote a high-precision pseudo-spectral (FFT) Python solver to monitor long-term simulation stability.
Numerical Validation Results:
\- Identity Check: Verified the algebraic condition across 1,000 randomized chaotic configurations down to pure machine precision (< 10\^-13).
\- Ultra-Long Term Simulation: Integrated the time-dependent system over 500,000 steps without a single hint of numerical divergence or NaN error. The kinetic energy decays monotonically and smoothly.
\- Ideal MHD Stress Test: Tested the same operator under absolute zero-viscosity conditions for 10,000 steps. The solver successfully absorbed the hyper-turbulent coupling without numerical collapse.
The full project is hosted on GitHub under a GNU GPL v3.0 license:
GitHub Repository: https://github.com/
I'm sharing this here to get your thoughts and technical feedback. Let me know what you think!
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:
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.
TL;DR
- One data-level diagnostic workflow, applied to six battery fleets from five public sources (NASA PCoE; CALCE/UMD — the CS2 and CX2 series; MIT/Severson; Oxford; HUST). Every prediction was written down and hashed before the corresponding experiment ran — one of them with a publicly timestamped, Bitcoin-seeded protocol anyone can verify.
- Diagnosis mode: on the HUST fleet (77 cells, never touched before), we predicted an error-reduction band of [−45%, −20%] before modeling. Measured: −34.4%. Hit.
- Design mode: using only the manufacturer's spec sheet (max continuous charge current, 4A) plus Joule's law, we located the empirically best fast-charging policy in the MIT/Severson fleet within 2.2% of the measured optimum — before looking at any lifetime data.
- We also publish two clean falsifications: sealed predictions that missed. They stay in the record.
- We are not publishing the algorithm. We are publishing protocols, data sources, and verdicts.
Battery RUL papers are full of numbers that were polished after the fact. We wanted protection against our own hindsight bias, so every experiment in this campaign follows the same rule: the prediction — with explicit numeric bands — is written to a dated, hashed document before the experiment runs. Afterward we score against the sealed document, not against our memory. Two of our sealed predictions failed. Both failures are below, unchanged.
The task: predict remaining useful life (RUL) under strict fleet-level protocols (leave-one-battery-out or leave-one-batch-out, nested train-only CV for all choices, official splits where they exist). Two task modes are used, and we label them explicitly: (a) lifetime from early data — MIT only, features from cycles ≤ 100 predict the full cycle life; (b) online RUL — all other fleets, at each cycle the model uses only data up to that cycle (no future information). Baseline ("naive") uses cycle count + current capacity only; the treatment adds an early-life feature set selected by the diagnostic. Leverage = (naive − treated) / naive, computed against the deployed treated configuration in every row.
Fleet Protocol Naive RMSE Treated RMSE (deployed) Leverage
NASA Li-ion (B0005/6/18) nested LOBO (b) 11.34 7.03 −38.0%
MIT/Severson (124 cells) official split (a) 248.8 (primary) / 481.4 (secondary) 128.7 (primary) / 189.9 (secondary) −48.3% / −60.6%
CALCE CS2 (4 cells) LOBO (b) 10.82 10.82 (suite declined features) 0% — called in advance
Oxford Degradation (8 cells) nested LOBO (b) 76.5 56.9 (deployed); 51.4 best subset −25.6% (subset: −32.8%)
HUST (77 cells, 10 batches) leave-one-batch-out (b) 58.7 38.5 −34.4%
CALCE CX2 (7 prismatic cells) nested LOBO (b) 81.2 63.4 −21.9% (see §3b)
Oxford note: the deployed treated model (56.9 RMSE, −25.6%) is the number the sealed band prediction was scored against in §5 — the post-hoc best subset (51.4, −32.8%) is reported for completeness but is not the deployed figure.
The CALCE row deserves explanation: before modeling, our diagnostic said this fleet has "nothing to repair," so the suite declined to add features and deployed the baseline. It was right — adding features made things worse (23.68 vs 10.82). Knowing when not to act is half the value of a diagnostic.
2b. Benchmark position — same-protocol comparisons only
We compare numbers only where the protocol matches, and we cite the source for every literature figure. RMSE in cycles; primary / secondary test sets as defined in each source.
MIT/Severson official split (41 train / 43 primary / 40 secondary), EOL = capacity < 0.88 Ah, features from cycles ≤ 100 only:
Model Primary Secondary
Severson et al. — discharge model (Table 1) 91 173
Severson et al. — variance model (Table 1) 138 196
Severson et al. — full model (Table 1) 118 214
BatteryML (Microsoft, ICLR 2024) — MATR-1/2 dummy baseline 398 510
Ours (diagnostic-selected features, ridge) 128.7 189.9
Position: we beat the variance and full models on the secondary set and the variance model on the primary set; the discharge-curve model (91/173) remains ahead of us. Our dummy-baseline check (392.8 / 491.8) lands within 1.3% (primary) and 3.6% (secondary) of BatteryML's published reproduction (398 / 510), which independently anchors that our split and labels match the literature pipeline.
NASA Li-ion: no comparison claimed. Most published NASA numbers train and test on cycles of the same battery; ours is leave-one-battery-out across different cells. Those protocols measure different things, so we do not put the numbers side by side.
HUST / Oxford / CALCE: run under our own strict fleet-level protocols (below); we are not aware of published results under identical protocols, so we report absolute numbers only.
We deliberately make no "SOTA" or "record" claims anywhere in this post. Every number above comes from our own runs; literature figures are quoted with their sources.
Across the first five fleets we noticed the leverage is not random — it tracks how heterogeneous the fleet is. We formalized this with two dispersion indices computed from early-life data only [we are keeping the exact definitions unpublished], and a band rule that maps index values to expected leverage. Then we tested it on a fleet we had never touched:
> Sealed prediction (before any HUST modeling): "Both indices fall in the mid band. Expected leverage: [−45%, −20%], central estimate ≈ −30%."
Measured: −34.4%.
Every fleet scored so far lands in its assigned band under the final dual-track diagnostic — one of them (HUST) fully pre-registered end-to-end, and one (Oxford) assigned correctly only after its original single-track call failed and forced the revision documented in §5. The sixth fleet gets its own section (§3b) with a fully public, cryptographically seeded protocol. For practitioners this is the useful takeaway: given a new fleet, early-life data alone can tell you in advance whether richer features are worth paying for.
3b. The cryptographically verifiable instance (sixth fleet, CX2)
For the sixth fleet (CALCE CX2 — a different prismatic cell and test rig from CS2), we ran the full public protocol, and this time the two heterogeneity indices disagreed — one landed in the mid band, the other near-flat. Our rule ("either-high governs") was thus facing its first hard case. Sequence, all timestamped:
2026-07-19 20:43 UTC — sealed prediction (band [−45%, −20%], falsification clause, full protocol) hashed and committed publicly: github.com/angus81226-glitch/sealed-predictions
After the commit — the experiment's random seed (741333625) was drawn from the hash of Bitcoin block 958777, the first block mined after the commitment. A proof-of-work block hash is unknowable until the moment it is solved — not even the miner knows it in advance — so the results could not have existed before the commitment did.
Experiment ran. Measured leverage: −21.9% — inside the sealed band. The sealed document is revealed in the same repo; anyone can re-hash it and compare against the 20:43 commitment.
One correction, disclosed in full in the repo (commitments/2026-07-20-cx2-verdict-v3-erratum.txt): the block's miner-declared header timestamp (20:33Z) predates our commit. Header stamps are not real time — in this very window, block 958776 is stamped older than its own parent — which is exactly why the protocol rests on the hash's unpredictability, not the header clock. We have since hardened the rule: future commits will name the chain tip (height + hash) explicitly, and the seed block's header time must be ≥ the commit time.
Six fleets, six correct band assignments under the final diagnostic — two of them pre-registered, one of them cryptographically verifiable by anyone. (Counting rigor: Oxford's original call failed, §5; its assignment under the revised dual-track diagnostic is correct. We count band assignments by the final diagnostic, and we count the failure openly.)
The MIT/Severson fleet cycled 124 cells under 72 distinct charging-policy strings in the authors' metadata — 64 standard two-step policies plus 8 'new-structure' variants from the follow-up batch — with measured lifetimes from 148 to 2237 cycles. We asked: can a balance-point calculation — attack energy vs. the cell's rated defense, using only public quantities (policy parameters, the manufacturer's 4A max continuous charge spec, Joule heating) — locate the optimum without lifetime data?
Results (all sealed in advance except where noted):
- The empirically best policy (3.6C to 80%) sits at balance ratio 0.978 — 2.2% from the predicted balance point of 1.0. The ratio is computed on Joule-weighted attack energy, i.e. R = (3.6/3.64)² = 0.978, not on raw current (which would give 3.6/3.64 = 0.989); the squared form follows from I²R heating and is stated here explicitly to avoid ambiguity.
- Death line: every policy above ratio 1.5 died before 1200 cycles. Correct.
- Ranking in the over-stressed region only worked after we added where-in-the-charge the stress lands (high rates late in the charge are far more damaging than the same energy early). Sealed prediction: correlation strengthens past |ρ| = 0.4. Measured: ρ = −0.60 (from −0.16). Hit.
- A second sealed refinement (rate-switch transient penalty) made things worse (ρ collapsed to −0.15). Falsified, removed, kept in the record.
4b. Full test protocols and exact parameters (reproduction-grade)
Everything below is exactly what we ran. The only items withheld are the diagnostic's selection logic; all engineering parameters are listed.
NASA Li-ion (B0005/6/18)
- EOL: discharge capacity < 80% of rated (B0005 = cycle 125)...
Hi!
I have made https://tako.atom.li/, where you can run many simulations directly in browser!
It lets you run computational chemistry simulations directly in your browser. All calculations run locally on your machine, and simulation data are not uploaded to my server.
Examples:
6K atoms TiO2 crystal rendering demo.
H2O vibration frequency @ gXTB.
Since your own CPU/GPU performs the calculations, start with small systems and avoid making jobs too large.
All engines are optimized to be even faster then the Fortran counterparts on 1 core, im working on portable GPU backend and parallelization.
Currently supported models/level of theory:
MLIPs(nequix, nequip, equiformer v2 are optimized for now)
DFT at GGA/mGGA
DFT at Skala 1.1 level
Tight-binding: gXTB and GFN2 are implemented. gXTB is still very experimental, current parameters are trained to approximate gxtb binary released by Grimme group.
I'll be grateful for any suggestion.
p.s. The documentation is pure slop for now, i'm still changing things around, i'm sorry for the poor document.
p.s. The sharing feature is based on P2P sharing, my server only facilitate the handshake, all data are encrypted before transfer. Also this means you have to keep the browser active for sharing.
Hi everyone,
We at Lamalab been working on OpenClatura, an open-source tool for generating systematic chemical names from SMILES.
The original motivation was to build something along the lines of ChemDraw’s structure-to-name feature, but open source and easier to inspect, modify, and test.
It is still early, and right now we are mainly looking for edge cases/setup problem and integration ideas. If you work with molecular structures, it would be very helpful if you could try it on one or two compounds and let us know where it fails, produces a strange name, or does not install correctly.
Installation
pip install openclatura
Command-line example
openclatura name "CC(=O)Nc1ccccc1"
Python example
from openclatura import name
result = name("CC(=O)Nc1ccccc1")
print(result.name)
GitHub:
https://github.com/lamalab-org/openclatura
Issues can be reported here:
https://github.com/lamalab-org/openclatura/issues
Blunt feedback is very welcome.
P.S Got aprovment from the mods, was told to mention that: )
Hey everyone,
I have recently studied and discussed a lot regarding how 'simulations' are being handled in agriculture. And today none of the tools quite provide flexibility or more importantly freedom and visualisation.
I wanted something different, something like a code-first virtual farm where I could actually see the physiology and environmental effects in 3D, without it feeling like a black box.
So, I built CropForge.
It’s an open-source, code-first virtual farm runtime. Instead of creating something which works with averages and considers means, I took a different approach and made it sensitive to the environment and allowed full flexibility over all maths and equations that are fed in, basically one can simply input anything they want.
I’ve just hit v1.0.0, which is the stable release and like I said it's fully flexible.
I’m looking for feedback from you all, regarding if you want to actually incorporate it into your research work. Does the API structure actually fit your workflows? I’d love for you to break it and tell me what’s missing.
TL;DR: I built CropForge which is a local, Python-based virtual farm runtime that visualizes crop physiology in 3D. It’s open-source, v1.0.0 is live, and I’m looking for technical feedback on the API.
GitHub: CropForge
>
This version invites discussion, shares raw metrics, removes the corporate branding, and asks the community a question at the end. It is much more likely to survive the moderators and spark a great technical debate.Hey everyone, I’ve been doing some deep architectural testing lately on predicting localized electronic properties (specifically band gaps), and I wanted to share some benchmarking results that might be useful if you're working with ML in materials science.
There is a huge push right now to use foundation models like MACE-MP-0 and CHGNet as silver bullets. They are undeniably incredible for total energy and interatomic force predictions. But I wanted to see what happens if we freeze their embeddings to predict band gaps.
The TL;DR: They failed pretty hard in my benchmarks.
I ran a strict, leakage-free empirical benchmark (ensuring formula-disjoint segregation so the test set was completely unseen). I compared frozen embeddings from CHGNet and MACE against a custom-built Graph Neural Network (GNN).
The custom GNN outperformed the foundation models by a massive 78% margin (achieving a Test MAE of 0.3389 eV).
Why the huge difference?
It comes down to how the architectures handle local orbitals. Foundation models pool and compress structural features, which inherently strips away the geometric sensitivity of localized orbitals.
To fix this, I engineered a custom GNN natively with 11-dimensional electronic features. Instead of just looking at coordinates, it explicitly reads electron configurations across $s, p, d,$ and $f$ orbitals and propagates this data via spatial message passing.
The Sanity Check (TiO2):
To prove the model wasn't just guessing based on stoichiometry, I tested it on Titanium Dioxide polymorphs. The model successfully distinguished between Rutile and Anatase phases with a 0.182 eV differential, recognizing the different spatial arrangements despite identical chemical formulas.
I’ve attached a video of the UI I built for the engine processing this in real-time.
Has anyone else run into this specific limitation when trying to repurpose structural foundation models for electronic/quantum properties? Curious to hear how others are handling orbital sensitivity in their pipelines!This version invites discussion, shares raw metrics, removes the corporate branding, and asks the community a question at the end. It is much more likely to survive the moderators and spark a great technical debate.
This is a shot in the dark to citizen-scientists / other academics. I'm looking for potential collaborators.
I have been having great success using Fable + Opus to write CUDA code for numerical simulations on my local consumer grade rig (V100s, RTX2080 Ti).
I am not an academic, but have a great interest in error detection and correction.
I have just completed an exhaustive search for a class of CRC-32 generator polynomials that are simultaneously able to correct single error bursts (SBC) of up to 5-bits while guaranteeing that no two error bursts with the same characteristics are in the data of interest (DBD).
I have the complete population statistics for all CRC-32 generator polynomials.
I can reproduce the results in around 1 day -- this required considerable effort.
There are 18 winners, each with a particular algebraic structure that lands the SBC+DBD range north of 1 kiB. I have the exact profile for the standard CRC-32 generator polynomial, which has a SBC+DBD range of around 150 bytes. These figures are approximate, but I have measured and cataloged these down to the exact bit for every CRC-32 generator polynomial.
Further analysis is required, but I believe these winners also have good HD=6 error detection ranges.
Some pictures..
No, I did not do the Math. That's Fable + Opus. My main contribution was sponsoring the activity in my now very warm room (winter here :-) The other contribution from me was decades of low-level code optimization. I basically forced the LLM to try many different hacks to get the simulation speed to acceptable levels (Original ETA was 188 days now 1 day)
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:
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.
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).
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/
I am a researcher specializing in diagnosing numerical anomalies and analyzing parameter consistency in multi-physics coupling simulations, with a self-developed mathematical framework dedicated to dissecting the mathematical root causes of simulation crashes and identifying self-consistent parameter combinations. This framework not only pinpoints problem sources but also enables reverse derivation and optimization of entire data systems. Only verified analytical conclusions will be shared—I will not disclose the internal calculation methods.
Over the past few months, I have applied this unified underlying logic to 37 cross-domain cases, covering fluid dynamics, heat transfer, structural mechanics, and electromagnetic coupling. Even when problems belong to entirely different physical domains, the framework integrates and derives insights through a single model, eliminating the need to calculate each discipline separately or align terminology across multiple experts.
My core philosophy is that all physical phenomena are composed of fundamental physical quantities; integrated mathematical analysis avoids splitting calculations by domain, streamlining the process. To clarify the scope of my research: I can perform mathematical validation of data anomaly sources, parse parameters in cross-scale coupling problems, verify the self-consistency of physical models, and optimize global parameter matching. All outputs are purely mathematical calculations—their accuracy depends entirely on the completeness and accuracy of the input data, and they are not equivalent to physical test results.
I explicitly do not handle: visual interface design, pure coding development, time-based casual consultations, or financial data analysis (my model is based on physical domains and does not apply to finance). Beyond finance, I can analyze data from all physical and engineering sciences.
If you have data or simulation problems that conventional analysis methods cannot resolve, or if you suspect logical inconsistencies in your existing computational results, feel free to discuss them with me. To improve communication efficiency, please include these details when sharing your problem: the physical field involved (e.g., fluid, thermal, structural mechanics, electromagnetics), the types of data you have (e.g., temperature curves, stress distributions, time-series data), the specific questions you want to address (e.g., why simulations diverge, whether a parameter is at a critical value, parameter tuning directions, how to reverse-optimize data), and the solutions you have already tried along with the specific bottlenecks you are encountering.
Can someone please tell me why these two codes don't give the same answer?
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()
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 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:
Does the code run successfully in a clean Python environment?
Can the reported numerical results be reproduced?
Are any target values hard-coded, fitted, or indirectly reused?
Are there any hidden adjustable parameters or circular dependencies?
Are the mathematical rules correctly implemented in the code?
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.
I am a researcher specializing in diagnosing numerical anomalies and analyzing parameter consistency in multi-physics coupling simulations, with a self-developed mathematical framework dedicated to dissecting the mathematical root causes of simulation crashes and identifying self-consistent parameter combinations. This framework not only pinpoints problem sources but also enables reverse derivation and optimization of entire data systems. Only verified analytical conclusions will be shared—I will not disclose the internal calculation methods.
Over the past few months, I have applied this unified underlying logic to 37 cross-domain cases, covering fluid dynamics, heat transfer, structural mechanics, and electromagnetic coupling. Even when problems belong to entirely different physical domains, the framework integrates and derives insights through a single model, eliminating the need to calculate each discipline separately or align terminology across multiple experts.
My core philosophy is that all physical phenomena are composed of fundamental physical quantities; integrated mathematical analysis avoids splitting calculations by domain, streamlining the process. To clarify the scope of my research: I can perform mathematical validation of data anomaly sources, parse parameters in cross-scale coupling problems, verify the self-consistency of physical models, and optimize global parameter matching. All outputs are purely mathematical calculations—their accuracy depends entirely on the completeness and accuracy of the input data, and they are not equivalent to physical test results.
I explicitly do not handle: visual interface design, pure coding development, time-based casual consultations, or financial data analysis (my model is based on physical domains and does not apply to finance). Beyond finance, I can analyze data from all physical and engineering sciences.
If you have data or simulation problems that conventional analysis methods cannot resolve, or if you suspect logical inconsistencies in your existing computational results, feel free to discuss them with me. To improve communication efficiency, please include these details when sharing your problem: the physical field involved (e.g., fluid, thermal, structural mechanics, electromagnetics), the types of data you have (e.g., temperature curves, stress distributions, time-series data), the specific questions you want to address (e.g., why simulations diverge, whether a parameter is at a critical value, parameter tuning directions, how to reverse-optimize data), and the solutions you have already tried along with the specific bottlenecks you are encountering.
Gloxel v1.6.34l · Surface Thermal Memory
I've made a planet generator and weather simulator out of famous mathematical equations. It has many options for visualization and model resolution so should work on nearly any computer and also tax the most powerful of machines. Cranked up some of the images are beautiful. It is a very early development version, only a few months or so into it but i find it surprisingly interesting already... 9 brings up options, 0 engages fullscreen and x exports image and data packs. The json output could be used for world building i think but I have not tested that yet, some feedback would be wonderful...enjoy!