Add Grid.Mesh2_face_links

[erogluorhan]

(optional)

A DataArray of indices indicating faces that are neighboring each face.

Grid.Mesh2_face_links: int DataArray of size (nMesh2_face, MaxNumNodesPerFace)

[philipc2]

Given our naming convention, we will probably refer to this connectivity as face_face_connectivity

[erogluorhan]

Given our naming convention, we will probably refer to this connectivity as face_face_connectivity

Yes, I thought the same thing, but UGRID refers to the variable name for this connectivity as "Mesh2_face_links" (though we know those UGRID names are only for exemplification purposes, I think we'd still stick to it).

[philipc2]

Given our naming convention, we will probably refer to this connectivity as face_face_connectivity

Yes, I thought the same thing, but UGRID refers to the variable name for this connectivity as "Mesh2_face_links" (though we know those UGRID names are only for exemplification purposes, I think we'd still stick to it).

I'm still in favor of face_face since that's consistent with the rest of the naming convention.

@hongyuchen1030 any thoughts?

[hongyuchen1030]

Given our naming convention, we will probably refer to this connectivity as face_face_connectivity

Yes, I thought the same thing, but UGRID refers to the variable name for this connectivity as "Mesh2_face_links" (though we know those UGRID names are only for exemplification purposes, I think we'd still stick to it).

I'm still in favor of face_face since that's consistent with the rest of the naming convention.

@hongyuchen1030 any thoughts?

I feel like sticking with UGRID convention might be better choice. But that's based on my assumption that all rest of our naming are based on UGRID as well. As long as our naming is consistent to one rule, I feel it's fine.

Just a quick note about these attributes.

As previously mentioned, mesh arrangements can also be employed to achieve similar functionality:

Initially, we traverse through the input to create a single data structure that encapsulates all the pertinent information.

Subsequently, when there's a need to access a specific attribute, we can simply perform a query on this data structure. This enables us to retrieve the result in O(logn) time complexity.

Essentially, this approach negates the necessity to store various connectivity details across multiple arrays. Instead, we consolidate them into a single data structure once and access the required information through subsequent queries.

But again, these are just some information I think you might be interested and I am open to any development idea

[erogluorhan]

@hongyuchen1030 It sounds worth exploring it. I am curious about the time complexity and memory needed for the initial mesh arrangements to be calculated

[philipc2]

Given our naming convention, we will probably refer to this connectivity as face_face_connectivity

Yes, I thought the same thing, but UGRID refers to the variable name for this connectivity as "Mesh2_face_links" (though we know those UGRID names are only for exemplification purposes, I think we'd still stick to it).

I'm still in favor of face_face since that's consistent with the rest of the naming convention. @hongyuchen1030 any thoughts?

I feel like sticking with UGRID convention might be better choice. But that's based on my assumption that all rest of our naming are based on UGRID as well. As long as our naming is consistent to one rule, I feel it's fine.

Just a quick note about these attributes.

As previously mentioned, mesh arrangements can also be employed to achieve similar functionality:

Initially, we traverse through the input to create a single data structure that encapsulates all the pertinent information.

Subsequently, when there's a need to access a specific attribute, we can simply perform a query on this data structure. This enables us to retrieve the result in O(logn) time complexity.

Essentially, this approach negates the necessity to store various connectivity details across multiple arrays. Instead, we consolidate them into a single data structure once and access the required information through subsequent queries.

But again, these are just some information I think you might be interested and I am open to any development idea

This is worth exploring, especially for constructing a majority of the connectivities that a dataset might not contain. I still need to do some reading into it to better understand it though.

However, for now I've mostly been thinking in terms of datasets that already come with these connectivity's (face_face are in MPAS datasets, in the variable cellsOnCel)

[hongyuchen1030]

Given our naming convention, we will probably refer to this connectivity as face_face_connectivity

Yes, I thought the same thing, but UGRID refers to the variable name for this connectivity as "Mesh2_face_links" (though we know those UGRID names are only for exemplification purposes, I think we'd still stick to it).

I'm still in favor of face_face since that's consistent with the rest of the naming convention. @hongyuchen1030 any thoughts?

I feel like sticking with UGRID convention might be better choice. But that's based on my assumption that all rest of our naming are based on UGRID as well. As long as our naming is consistent to one rule, I feel it's fine. Just a quick note about these attributes. As previously mentioned, mesh arrangements can also be employed to achieve similar functionality: Initially, we traverse through the input to create a single data structure that encapsulates all the pertinent information. Subsequently, when there's a need to access a specific attribute, we can simply perform a query on this data structure. This enables us to retrieve the result in O(logn) time complexity. Essentially, this approach negates the necessity to store various connectivity details across multiple arrays. Instead, we consolidate them into a single data structure once and access the required information through subsequent queries. But again, these are just some information I think you might be interested and I am open to any development idea

This is worth exploring, especially for constructing a majority of the connectivities that a dataset might not contain. I still need to do some reading into it to better understand it though.

However, for now I've mostly been thinking in terms of datasets that already come with these connectivity's (face_face are in MPAS datasets, in the variable cellsOnCel)

I have included more documentation that you might find useful CGAL_Mesh_Arrangement

And in the section 3.4 Batched Point-Location, it stated

The batched point-location operation is carried out by sweeping the arrangement. Thus, it takes O((m+N)log(m+N)) time, where N is the number of edges in the arrangement.

So my current thought is:

If all these connectivities are given from the input files, then we can just stored them into different connectivity array.

However, if we need to retrieve these connectivity ourselves, it's always beneficial to take a look into how the computational geometry community handle such problems, given the complex nature of the curved surface.