Add Large diffusion example (250k atoms, KOKKOS)#379
Conversation
Same physics as the Diffusion example but with `variable L equal 50.0` — ~250,000 LJ atoms (50x50x25 fcc cells) — placed right after Diffusion in the library. Runs multithreaded via the `suffix kk` marker; browser-verified at ~59 timesteps/second with pair lj/cut/kk, and the app stays healthy after. Camera directives scaled with the box (same framing as the original). The screenshot is a placeholder (copy of the Diffusion image) to be replaced with a real capture. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request expands the project's simulation examples by adding a high-atom-count diffusion scenario. The new example is designed to leverage KOKKOS for improved multithreaded execution, providing a performance-oriented benchmark for users. The changes include the necessary input script and registration within the application's example manifest. Highlights
New Features🧠 You can now enable Memory (public preview) to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console. Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize the Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counterproductive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces a new "Large diffusion" simulation example, including its LAMMPS input script and its metadata configuration in examples.json. It also cleans up the indentation of some existing entries in the JSON file. The review feedback highlights three main improvement opportunities: simplifying redundant immediate evaluation syntax in the LAMMPS script, using the correct dynamic variable reference syntax (v_name) instead of immediate text substitution, and correcting an inverted markdown link syntax in the simulation's description.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
| #/atom 2 1.5 #ff0000 | ||
|
|
||
| variable L equal 50.0 | ||
| variable Lhalf equal $(0.5*v_L) |
There was a problem hiding this comment.
In LAMMPS, using immediate evaluation $(...) inside an equal style variable definition is redundant and can be simplified. Defining Lhalf as a standard formula 0.5*v_L is cleaner and more idiomatic.
variable Lhalf equal 0.5*v_L
| variable left equal 0.5*$L-0.5*${thickness} | ||
| variable right equal 0.5*$L+0.5*${thickness} |
There was a problem hiding this comment.
In LAMMPS, equal-style variables should reference other variables using the v_name syntax (e.g., v_L and v_thickness) rather than immediate text substitution ($L and ${thickness}). Using v_name ensures that the formulas are evaluated dynamically and follow standard LAMMPS scripting best practices.
variable left equal 0.5*v_L-0.5*v_thickness
variable right equal 0.5*v_L+0.5*v_thickness
| "id": "large_diffusion", | ||
| "title": "Large diffusion", | ||
| "description": "A large version of the diffusion example (~250,000 atoms) that runs multithreaded with KOKKOS. The white atoms have mass 1 while the red atoms have mass 4.", | ||
| "analysisDescription": "# About this simulation\nWe simulate two Lennard Jones particle types with masses 1.0 and 4.0. The diffusion coefficient [https://en.wikipedia.org/wiki/Mass_diffusivity](scales like) D$\\propto 1/\\sqrt{m}$, so we should see a factor 2 higher diffusion coefficient for the small molecules.", |
There was a problem hiding this comment.
The markdown link syntax in analysisDescription is inverted. In markdown, the format is [link text](URL). It should be [scales like](https://en.wikipedia.org/wiki/Mass_diffusivity) instead of [https://en.wikipedia.org/wiki/Mass_diffusivity](scales like).
| "analysisDescription": "# About this simulation\nWe simulate two Lennard Jones particle types with masses 1.0 and 4.0. The diffusion coefficient [https://en.wikipedia.org/wiki/Mass_diffusivity](scales like) D$\\propto 1/\\sqrt{m}$, so we should see a factor 2 higher diffusion coefficient for the small molecules.", | |
| "analysisDescription": "# About this simulation\nWe simulate two Lennard Jones particle types with masses 1.0 and 4.0. The diffusion coefficient [scales like](https://en.wikipedia.org/wiki/Mass_diffusivity) D$\\propto 1/\\sqrt{m}$, so we should see a factor 2 higher diffusion coefficient for the small molecules.", |
The hardcoded /atomify/ prefix got base-prepended again by Vite's dev HTML transform (-> /atomify/atomify/... 404). A relative src resolves against the page URL in both dev and the production build. Harmless in dev beyond the noise (vite serves COOP/COEP headers directly and the shim no-ops when already isolated), but now it loads cleanly everywhere. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Vite's dev transform rewrote the ~43 MB emscripten module and appended an
inline sourcemap, inflating the worker's fetch to ~460 MB — slow at best,
and enough to crash the tab ("Aw, Snap! error code 5"). The module is only
ever loaded via `?url` + fetch-as-blob, never bundled, so a small dev-only
middleware now streams the file as-is before Vite's transform runs
(`?url`/`?import` shim requests still go through Vite untouched).
Verified: dev download is 41.4 MB with a correct Content-Length, the module
loads in ~2 s, simulations run; production build unaffected.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Replaces the placeholder (copy of the Diffusion image) with a capture of the actual 250k-atom simulation, resampled to 1000px wide to match the other example images. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
1 participant
Adds Large diffusion next to the Diffusion example: identical physics with
variable L equal 50.0→ ~250,000 LJ atoms, running multithreaded via thesuffix kkmarker.pair lj/cut/kk, no errors, app healthy afterwards.large_diffusion.pngis a placeholder (copy of the Diffusion image) — to be replaced with a real capture before/after merge.🤖 Generated with Claude Code