[Core][Future] New data containers for entities

[loumalouomega]

---

name: ✨ Feature
about: New data containers for entities

📝 Description

Adds a Kratos::Future entity-data manager that lets the entities of a ModelPart — Node, Element, Condition, Geometry, MasterSlaveConstraint — use the new core DataContainer (from core/new-data-containers) as a parallel, DataContainer-backed storage path, alongside their existing storage. The integration lives entirely under kratos/future/ and is compiled only with -DKRATOS_USE_FUTURE=ON; no entity class, and no existing storage/serialization/hot path, is touched. When the flag is off, nothing changes.

The access point is at ModelPart level (model_part_data.Nodes().GetValue(node, VAR)), not on the entity classes. This is a deliberate design decision: KRATOS_USE_FUTURE is scoped to KratosCore's own compilation and does not reach application translation units, so an #ifdef-gated data member on Node/Element/… would give those classes a different layout in core vs. in applications — a silent ABI/ODR break. Keeping the storage in a ModelPart-owned manager avoids any entity-layout change.

Continues #14587

Key changes

• Future::EntityDataContainer (kratos/future/containers/entity_data_container.{h,cpp}) — the bridge between Id-addressed entities and the slot-addressed DataContainer. Owns one DataContainer plus an Id → dense slot map. Entities are registered (slots assigned in registration order); variables are added per container:
  • AddVariable(V) → non-historical dense (NonHistoricalDataPolicy),
  • AddHistoricalVariable(V) → TimeStep-buffered (HistoricalDataPolicy, buffer size from the ModelPart),
  • raw Add(V, value_policy, history_policy) passthrough for sparse/custom.
    Access via GetValue/SetValue/Has (by entity or Id, with an optional step for historical data) and O(1) bulk access via GetDataSpan(accessor)[Index(entity)]. Dense chunks grow automatically as entities register (via DataContainer::Resize).
• Future::ModelPartDataContainer (model_part_data_container.{h,cpp}) — a per-ModelPart aggregate exposing one EntityDataContainer per entity kind (Nodes(), Elements(), Conditions(), Geometries(), MasterSlaveConstraints()), snapshotting the entities at construction, plus Update() (register entities added later) and CloneStepData(StepCategory) (advance historical buffers in lockstep with ModelPart::CloneTimeStep).
• Python bindings (add_entity_data_to_python.{h,cpp}, registered in future/python/kratos_python.cpp): both classes under KratosMultiphysics.Future, per-type Add/Get/Set for double/int/array_1d<double,3>/std::string, and zero-copy NumPy spans reusing the Phase I DataContainer bindings.
• Docs: a Phase II section in docs/pages/Kratos/For_Developers/Data_Structures/Data_Container.md (architecture, old-API → manager-API mapping, and the limitation list).

Notable semantic point for reviewers: Element/Condition non-historical data traditionally lives on the shared Geometry, so two elements over the same geometry share it. The manager keys by element/condition Id, so those values are independent per entity — an intentional difference, documented.

Known limitations (documented, out of scope here): component variables (e.g. DISPLACEMENT_X) and ublas Vector/Matrix cannot be stored (the value policy needs a bool operator==, and a component's source type cannot be recovered from Variable<double>); entity removal leaves an unreclaimed slot hole; buffer size is snapshotted at construction; no serialization/MPI of the manager data yet; the manager must not outlive its Model.

Validation

Configure with -DKRATOS_USE_FUTURE=ON, then:

• C++: KratosCoreTest --gtest_filter='KratosCoreFutureSuite.*EntityDataContainer*:KratosCoreFutureSuite.*ModelPartDataContainer*' → 15/15 pass (registration/growth/error paths/shallow-copy; per-node historical + non-historical round trips with CloneTimeStep+CloneStepData; both-way non-contamination against the legacy FastGetSolutionStepValue/GetValue; Update; element/condition independence; geometries incl. a standalone one; master-slave constraint; an end-to-end loop).
• Python: python3 kratos/future/tests/test_entity_data_container.py → 9/9 pass (registered in test_KratosFutureCore.py, run via the hasattr(KratosMultiphysics, "Future") guard in test_KratosCore.py).
• Full regression: complete KratosCoreTest passes with Future ON.
• Flag-off safety: reconfiguring with -DKRATOS_USE_FUTURE=OFF and rebuilding compiles cleanly — nothing outside kratos/future/ references the new classes.

🆕 Changelog

• Added Future::EntityDataContainer — maps a ModelPart's entities onto a chunked DataContainer (Id→slot), with non-historical, historical and sparse variables.
• Added Future::ModelPartDataContainer — per-ModelPart aggregate exposing DataContainer-backed storage for nodes, elements, conditions, geometries and master-slave constraints, with CloneStepData/Update.
• Added KratosMultiphysics.Future Python bindings for both classes (per-type Add/Get/Set + NumPy spans).
• Added C++ (KratosCoreFutureSuite) and Python (test_entity_data_container.py) test coverage.
• Added a Phase II section to the DataContainer developer docs.
• All additive and gated behind KRATOS_USE_FUTURE; entity classes and their existing storage are unchanged.