|
PICurv 0.1.0
A Parallel Particle-In-Cell Solver for Curvilinear LES
|
PICurv uses a robust locate-and-migrate pipeline so every particle ends each step with a valid owner rank and host cell (or is explicitly marked lost).
A particle is tested against candidate cell faces using signed distances. Search starts from prior cell information when available, then walks to neighboring cells by face-crossing logic until a terminal status is reached.
This avoids expensive global brute-force lookup and is suitable for distributed curvilinear grids.
Location/migration logic uses ParticleLocationStatus:
NEEDS_LOCATIONACTIVE_AND_LOCATEDMIGRATING_OUTLOSTUNINITIALIZEDThese statuses drive the iterative migration passes in the orchestrator.
LocateParticleOrFindMigrationTarget (walking-search module)The current orchestrator includes:
For restart-loaded particles with valid CellID, PICurv can skip full walking search and directly resolve owner rank via cell ownership map before migration. This is usually much cheaper than full re-location on first restart step.
Current direct coverage is strongest at the orchestrator level:
LocateAllParticlesInGrid has dedicated direct tests for the prior-cell fast path and the local guess-then-verify pathMigrateRestartParticlesUsingCellIDCurrent direct gaps still targeted for the next remediation are:
LocateParticleOrFindMigrationTargetLOST and MIGRATING_OUTGuessParticleOwnerWithBBox heuristicWatch for:
LOST particles,logs/search_metrics.csv,search_failure_fraction, search_work_index, or re_search_fraction,lost or lost_cumulative even when migration otherwise appears healthy.For precise metric definitions and formulas, see Search Robustness Metrics Reference.
These usually indicate domain-decomposition mismatch, bounding-box mismatch, or invalid particle coordinates.
See Common Fatal Errors and Fixes for troubleshooting commands.
This page describes Walking Search for Particle Location within the PICurv workflow. For CFD users, the most reliable reading strategy is to map the page content to a concrete run decision: what is configured, what runtime stage it influences, and which diagnostics should confirm expected behavior.
Treat this page as both a conceptual reference and a runbook. If you are debugging, pair the method/procedure described here with monitor output, generated runtime artifacts under runs/<run_id>/config, and the associated solver/post logs so numerical intent and implementation behavior stay aligned.