feat: field property entity data offsets#3173
Open
PProfizi wants to merge 11 commits into
Open
Conversation
Co-authored-by: Copilot <copilot@github.com>
Co-authored-by: Copilot <copilot@github.com>
Co-authored-by: Copilot <copilot@github.com>
Co-authored-by: Copilot <copilot@github.com>
❌ 32 Tests Failed:
View the top 3 failed test(s) by shortest run time
To view more test analytics, go to the Test Analytics Dashboard |
Collaborator
|
@PProfizi I honestly see value in the denomination Having said that, Everything in DPF Kernel and public APIs refers to this concept as data_pointer/dataPointer, so any user familiar with the concept already understands it. I'd advocate for documenting it extensively so any user can understand it, but not so much for changing its name. |
Contributor
Author
|
I think you are a little biased @rafacanton ;) |
Collaborator
|
@PProfizi It is implicit indeed, until you see that it is a vector that has the size of the scoping. As for the alias, I see value on it, specially because offsets seems a much more common way to call this in other tools, like vtk (https://docs.vtk.org/en/v9.4.0/design_documents/VTKFileFormats.html). We could have both, with the alias calling |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This pull request refactors the handling and naming of entity data offsets in DPF fields to use the new, clearer
entity_data_offsetsproperty instead of the previous_data_pointerterminology. This improves code clarity, consistency, and documentation, and updates all relevant code, tests, and documentation accordingly. The changes also add better documentation and examples for working with variable-size entity data, especially forelemental_nodalfields.API and Naming Refactor:
entity_data_offsetsproperty (with getter and setter) as the public interface for accessing the start indices of each entity's data in the flat data array, replacing the previous_data_pointerattribute. The private alias is kept for backward compatibility. [1] [2]entity_data_offsetsinstead of_data_pointer, improving naming consistency and making the API clearer for users. [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13]Documentation and Tutorials:
elemental_nodalfields with detailed examples and explanations of how to useentity_data_offsetsfor both incremental and bulk data assignment. [1] [2]entity_data_offsets, clarifying its purpose and usage for fields with variable-size entity data. [1] [2]Codebase and API Consistency:
entity_data_offsetsinstead of_data_pointer, ensuring consistent access throughout the codebase. [1] [2]entity_data_offsetstoStringField, aligning its API with other field types. [1] [2] [3]Deep Copy and Field Operations:
entity_data_offsetsinstead of copying the private pointer, ensuring correct behavior for fields with variable-size entity data.These changes make the handling of variable-size entity data more transparent and user-friendly, while maintaining backward compatibility for existing code.