I just ask Mistral AI for an analysis of the different pattern in sofa regarding the initialization of Data<> d_indices.

I put here the summary to avoid consuming token asking the same question in the future.

Analysis of indices / index Data in SOFA Components

This report analyzes all components inheriting from BaseComponent that have Data fields named "indices" or "index" (members d_indices, d_index, f_indices, etc.). The goal is to identify naming, typing, and initialization pattern inconsistencies across components, with a view toward unification.

The analysis covers:

• Data declaration (exposed name, member name, type)
• Constructor initialization patterns
• Initialization patterns in ::init() and ::reinit()
• Auto-fill behaviors (full or partial)

1. Summary of Types Used

2. Components by Declaration Pattern

Pattern 1 — initData(&d_indices, "indices", "description") no default value

The most widespread pattern. Data named "indices", member d_indices, no explicit default value.

Projective Constraints (all use TopologySubsetIndices aliased as SetIndex or IndexSubsetData)

Lagrangian Constraints

Mappings

ForceFields / Mass

Engines (ROI / Select / Analyze / Generate)

Pattern 2 — initData(&d_index, (unsigned)0, "index", "description") with default value 0

Data named "index" (singular), member d_index, scalar type, default value 0.

Pattern 3 — INCONSISTENT: initData(&d_index, "indices", "description")

Member named d_index (singular) but Data named "indices" (plural), vector type.

This is the only case where the member is d_index but the exposed name is "indices". All other components with a d_index member use the name "index".

Pattern 4 — initData(&f_indices, "indices", "description") f_ prefix (engines)

Data named "indices", member f_indices (engine convention: f_ = field/input), no default value.

Pattern 5 — this, "indices", "description", DataEngineInput/Output (new vectorData style)

Uses core::objectmodel::vectorData<T> with the modern constructor this, "name", "desc", DataEngineInput.

MeshSplittingEngine also has edgeIndices, triangleIndices, quadIndices, tetrahedronIndices, hexahedronIndices — all in vectorData<SetIndices>.

Pattern 6 — std::array<TopologySubsetIndices, 2> initialized in the declaration

Pattern unique to SpringForceField: a std::array of TopologySubsetIndices initialized directly in the member declaration.

// SpringForceField.h:148-151
std::array<sofa::core::topology::TopologySubsetIndices, 2> d_springsIndices
{
    sofa::core::topology::TopologySubsetIndices {initData(&d_springsIndices[0], "springsIndices1", "List of indices in springs from the first mstate", true, true)},
    sofa::core::topology::TopologySubsetIndices {initData(&d_springsIndices[1], "springsIndices2", "List of indices in springs from the second mstate", true, true)}
};

Note: the exposed names are "springsIndices1" and "springsIndices2", not "indices".

Pattern 7 — Data names different from "indices" / "index"

3. Initialization Patterns in ::init() / ::reinit()

Pattern A — createTopologyHandler(topology): topology linkage

Components using TopologySubsetIndices systematically call d_indices.createTopologyHandler(_topology) in init() to enable topology change tracking.

Pattern B — Auto-fill if indices not set (isSet() / empty())

When the user does not provide indices, the component auto-generates them (0..N-1).

Pattern C — Index generation from d_first/d_last or proximity search

// SubsetMapping.inl:76-90
if (d_indices.getValue().empty() && d_first.getValue() != sofa::InvalidID) {
    indices.resize(last-first+1);
    for (Index i=0; i<indices.size(); ++i)
        indices[i] = first+i;
}
else if (d_indices.getValue().empty()) {
    // proximity search with d_radius
}

Pattern D — Index extension/resizing

Pattern E — Index validation (bounds)

Several ProjectiveConstraints validate that each index < mstate->getSize() and call removeConstraint(index) if invalid.

// Typical pattern (FixedProjectiveConstraint.inl:130+)
const SetIndexArray & indices = d_indices.getValue();
for (unsigned int i=0; i<indices.size(); ++i) {
    const Index index = indices[i];
    if (index >= maxIndex) {
        msg_error() << "Index " << index << " not valid!";
        removeConstraint(index);
    }
}

Pattern F — No index processing in init()/reinit()

Pattern G — Engines: setDirtyValue() in init(), update() in reinit()

All engines follow this pattern. Indices are computed in doUpdate(), not directly in init()/reinit().

Pattern H — reinit() calls init() (or vice versa)

Pattern I — Update via callback (DataTracker)

Pattern J — d_index scalar: never initialized in init/reinit

These components have no initialization logic for d_index in init()/reinit(). The constructor default value 0 is used as-is.

4. Auto-fill 0..N-1 (full or partial)

Full auto-fill 0..N-1 in init() / reinit()

Partial auto-fill (sub-sequence) in init() / reinit()

Default value [0] in the constructor (not in init()/reinit())

These components set index 0 as the sole default value in the constructor:

Note: this is not a 0..N-1 auto-fill, but a default value [0] (a single index).

Equivalent behavior via d_fixAll (without filling the vector)

Fallback "all indices" in doUpdate() (engines)

Auto-fill in recomputeIndices() (internal member, not a Data)

These two components have no d_indices Data — the fill concerns an internal member m_indices computed from d_points.

5. Pattern Summary Table

6. Key Inconsistencies Identified