feat: Get raw value for faces connectivity data.

[prmukherj]

This feature updates existing method to add a flag "flatten_connectivity" which changes its default return types to retrieve raw face connectivity data from surface field queries. It enables advanced users to directly access the vertex indices that define each face, which can be useful for custom post-processing or geometry interpretation.

Key Changes

• Update get_faces_connectivity_data to provide raw-outputs.

Example usage:

python 

faces_connectivity_request = SurfaceFieldDataRequest(
    surfaces=[VelocityInlet(settings_source=solver_session, name="inlet")],
    data_types=[SurfaceDataType.FacesConnectivity],
    flatten_connectivity=True,
)
faces_connectivity_data = field_data.get_field_data(faces_connectivity_request)

# Accessing face connectivity
faces_connectivity_data["inlet"].connectivity
# Output: array([  4,   3,   2, ..., 379, 382, 388], shape=(1518,), dtype=int32)

# Accessing structured data:
transform_faces_connectivity_data(faces_connectivity_data["inlet"].connectivity)

Notes

• The raw format directly returns vertex indices for each face without additional formatting or interpretation.
• This enhancement aligns with use cases requiring low-level mesh topology access.

Please see tests and documentation for detailed usage.

[prmukherj]

@abhishekchitwar, this will suffice the requirement you had for getting raw data from faces_connectivity?

[abhishekchitwar]

@abhishekchitwar, this will suffice the requirement you had for getting raw data from faces_connectivity?

Thanks, @prmukherj! This avoids the need to explicitly flatten the face connectivity data when converting it to VTK or any other format.

[prmukherj]

@abhishekchitwar, this will suffice the requirement you had for getting raw data from faces_connectivity?

Thanks, @prmukherj! This avoids the need to explicitly flatten the face connectivity data when converting it to VTK or any other format.

@abhishekchitwar, we have decided to update the behavior so as to return the flat structure by default. So no changes required from your end to flatten it out or to add the flag. Thank you.

[seanpearsonuk]

@abhishekchitwar, this will suffice the requirement you had for getting raw data from faces_connectivity?

Thanks, @prmukherj! This avoids the need to explicitly flatten the face connectivity data when converting it to VTK or any other format.

@abhishekchitwar, we have decided to update the behavior so as to return the flat structure by default. So no changes required from your end to flatten it out or to add the flag. Thank you.

@prmukherj We did propose deprecating the previous format, which would usually imply initially providing a separate, temporary means for accessing the new format (possibly a different data_type). Should we not be concerned if instead we're simply making a breaking change without any prior notification?

[abhishekchitwar]

@abhishekchitwar, this will suffice the requirement you had for getting raw data from faces_connectivity?

Thanks, @prmukherj! This avoids the need to explicitly flatten the face connectivity data when converting it to VTK or any other format.

@abhishekchitwar, we have decided to update the behavior so as to return the flat structure by default. So no changes required from your end to flatten it out or to add the flag. Thank you.

@prmukherj We did propose deprecating the previous format, which would usually imply initially providing a separate, temporary means for accessing the new format (possibly a different data_type). Should we not be concerned if instead we're simply making a breaking change without any prior notification?

I believe it would be good to introduce a flatten = True flag, while keeping the default behavior set too False to ensure that existing workflows remain unaffected.

[prmukherj]

@abhishekchitwar, this will suffice the requirement you had for getting raw data from faces_connectivity?

Thanks, @prmukherj! This avoids the need to explicitly flatten the face connectivity data when converting it to VTK or any other format.

@abhishekchitwar, we have decided to update the behavior so as to return the flat structure by default. So no changes required from your end to flatten it out or to add the flag. Thank you.

@prmukherj We did propose deprecating the previous format, which would usually imply initially providing a separate, temporary means for accessing the new format (possibly a different data_type). Should we not be concerned if instead we're simply making a breaking change without any prior notification?

I believe it would be good to introduce a flatten = True flag, while keeping the default behavior set too False to ensure that existing workflows remain unaffected.

yes, doing that only. Just that the flatten behavior will be the default one later, going forward. So we need a deprecation message.