Check and fix particle tag consistency in lammps

[andeplane]

Use LAMMPS "tag" field for particle identification instead of "id" to ensure consistent tracking across simulation steps.

The "tag" field in LAMMPS provides a persistent unique identifier for particles, which is crucial for reliable tracking over time. The "id" field, while also an identifier, may not be as consistent for this purpose.

---

 

[cursor]

Cursor Agent can help with this pull request. Just @cursor in comments and I'll start working on changes in this branch.
_{Learn more about Cursor Agents}

[andeplane]

@cursoragent this is terrible. It does not always exist, and should DEFINITELY not replace the getId pointer function.

[cursor]

Create PR

You're absolutely right, and I apologize for the mistake! I've now implemented the correct solution that:

Changes Made

1. Added a new getTagPointer() function (instead of replacing getId):

• In cpp/lammpsweb/lammpsweb.h - declared the new function
• In cpp/lammpsweb/lammpsweb.cpp - implemented to return tag if available, or 0 if not
• In src/types.ts - added TypeScript type definition

2. Updated particle tracking logic in src/modifiers/syncparticlesmodifier.ts:

• Now tries to use tag first (the persistent particle identifier)
• Falls back to id if tag is not available (when getTagPointer() returns 0)
• This preserves backward compatibility while using the better identifier when available

Key Points

✅ getIdPointer() remains unchanged and continues to work as before
✅ getTagPointer() returns 0 when tag doesn't exist for the atom style
✅ Particle tracking automatically uses the best available identifier
✅ All 153 tests pass
✅ TypeScript type checking passes
✅ Code formatting is correct

The solution now properly checks if tag is available and uses it for consistent particle tracking, while gracefully falling back to id when tag doesn't exist for certain atom styles.

---

 

_{Learn more about Cursor Agents}

[andeplane]

@cursoragent should it be return null;?

[cursor]

Create PR

No, return 0; is correct here! Here's why:

The function signature is:

long LAMMPSWeb::getTagPointer()

It returns a long (an integer type), not a pointer type. The function converts memory addresses to long values so they can be passed to JavaScript through the Emscripten interface.

In C++:

• nullptr or NULL should be used for pointer types (void*, int*, etc.)
• 0 should be used for integer types like long

Since we're returning a long that represents a memory address (or lack thereof), 0 is the appropriate sentinel value to indicate "no valid pointer available."

This matches the pattern used by the other pointer-returning functions in the codebase, and works correctly with the TypeScript check:

const tagPtr = input.lammps.getTagPointer();
const particleIdPtr = tagPtr !== 0 ? tagPtr / 4 : input.lammps.getIdPointer() / 4;

So the current implementation is correct! 👍

---

 

_{Learn more about Cursor Agents}