Open aaronzedwick opened 1 month ago
@philipc2 Thoughts on the API? Currently, I return a dual
grid object as its own thing. This made sense to me, as changing the original grid would be difficult due to the different dimensions.
@philipc2 Thoughts on the API? Currently, I return a
dual
grid object as its own thing. This made sense to me, as changing the original grid would be difficult due to the different dimensions.
This type of implementation is what I was envisioning, since we don't want anything to be replaced in-place when creating the dual grid.
Let's name it something like Grid.compute_dual(method=...)
, where we method
could indicate what type of dual we'd like to compute.
We should add functionality that can also convert a UxDataset
or UxDataArray
into it's "dual" form, which would involve making any face-centered data variable now node-centered, and vice-versa. This would however cause issues if the data variable is edge centered, since those edges would no longer exist.
This was the block that we were able to get working in the Notebook.
import uxarray as ux
from uxarray.constants import INT_DTYPE, INT_FILL_VALUE
import numpy as np
uxgrid = ux.open_grid("/Users/philipc/uxarray-gold/uxarray-gold/uxarray/test/meshfiles/geos-cs/c12/test-c12.native.nc4")
lonlat_t = [(lon, lat) for lon, lat in zip(uxgrid.node_lon.values, uxgrid.node_lat.values)]
# # Dictionary to track first occurrence and subsequent indices
occurrences = {}
# Iterate through the list and track occurrences
for index, tpl in enumerate(lonlat_t):
if tpl in occurrences:
occurrences[tpl].append((INT_DTYPE(index)))
else:
occurrences[tpl] = [INT_DTYPE(index)]
duplicate_dict = {}
for tpl, indices in occurrences.items():
if len(indices) > 1:
source_idx = indices[0]
for duplicate_idx in indices[1:]:
duplicate_dict[duplicate_idx] = source_idx
new_face_node_connectivity = uxgrid.face_node_connectivity.values.copy().ravel()
for idx, item in enumerate(new_face_node_connectivity):
# O(1)
if item in duplicate_dict:
new_face_node_connectivity[idx] = duplicate_dict[item]
new_face_node_connectivity = new_face_node_connectivity.reshape((uxgrid.n_face, uxgrid.n_max_face_nodes))
node_face_conn = {node_i: [] for node_i in range(uxgrid.n_node)}
for face_i, face_nodes in enumerate(new_face_node_connectivity):
for node_i in face_nodes:
if node_i != ux.INT_FILL_VALUE:
node_face_conn[node_i].append(face_i)
n_max_node_faces = -1
for face_indicies in node_face_conn.values():
if len(face_indicies) > n_max_node_faces:
n_max_node_faces = len(face_indicies)
node_face_connectivity = np.full((uxgrid.n_node, n_max_node_faces), INT_FILL_VALUE)
for node_idx, face_indices in enumerate(node_face_conn.values()):
n_faces = len(face_indices)
node_face_connectivity[node_idx, 0:n_faces] = face_indices
new_uxgrid = ux.Grid.from_topology(uxgrid.node_lon.values,
uxgrid.node_lat.values,
new_face_node_connectivity,
node_face_connectivity=node_face_connectivity)
Thanks @philipc2! I will see if I can help figure out what's going on.
It is definitely something with how you are updating and returning the grid, I did a very basic implementation just as a function inside the grid class, called by compute dual at the start, and it works perfectly. Red is the original grid.
It is definitely something with how you are updating and returning the grid, I did a very basic implementation just as a function inside the grid class, called by compute dual at the start, and it works perfectly. Red is the original grid.
Right, it'd be better to compare the grid objects returned in each case, specifically the merged nodes part in both cases (notebook and installed versions)
Check out this pull request on
See visual diffs & provide feedback on Jupyter Notebooks.
Powered by ReviewNB
It is definitely something with how you are updating and returning the grid, I did a very basic implementation just as a function inside the grid class, called by compute dual at the start, and it works perfectly. Red is the original grid.
Yeah, I'm almost wondering if there might be a bug somewhere in our Grid.from_topology()
. Going to do some more digging.
It is definitely something with how you are updating and returning the grid, I did a very basic implementation just as a function inside the grid class, called by compute dual at the start, and it works perfectly. Red is the original grid.
Yeah, I'm almost wondering if there might be a bug somewhere in our
Grid.from_topology()
. Going to do some more digging.
It's working now though? I think it was just a problem with pip install . I have been having trouble getting it to work. That's what the notebook is for, just testing.
This can come out of draft now?
@philipc2 Are you fine with me splitting this into two PRs and just handling the dual mesh here? That way we can just focus on that and get it merged instead of worrying about why the duplication stuff isn't working?
@philipc2 Are you fine with me splitting this into two PRs and just handling the dual mesh here? That way we can just focus on that and get it merged instead of worrying about why the duplication stuff isn't working?
Hi @aaronzedwick
I had a local branch with the changes split, let me get that pushed and set up as a PR.
@philipc2 Are you fine with me splitting this into two PRs and just handling the dual mesh here? That way we can just focus on that and get it merged instead of worrying about why the duplication stuff isn't working?
Hi @aaronzedwick
I had a local branch with the changes split, let me get that pushed and set up as a PR.
Awesome, thank you Philip!
@philipc2 This should be ready for review, I made a lot of changes and got it down from 8.69s to 127ms for the 120km benchmark.
@philipc2 This should be ready for review, I made a lot of changes and got it down from 8.69s to 127ms for the 120km benchmark.
That's a significant improvement, nicely done!
I'm checking the compatibility with #879 and we can see where to move from there.
Continuing one of my comments above, we should create a UxDataArray.get_dual()
method that keeps the data stored under the Data Array, but swaps the mapping such that:
Continuing one of my comments above, we should create a
UxDataArray.get_dual()
method that keeps the data stored under the Data Array, but swaps the mapping such that:
- Face Centered variables become Node Centered
- Node Centered variables become Face Centered
- An error is raised for edge centered variables
Data array or dataset? We load in datasets more often than anything else, right?
Also, something with the latest commits to main messed up my tests.
Continuing one of my comments above, we should create a
UxDataArray.get_dual()
method that keeps the data stored under the Data Array, but swaps the mapping such that:
- Face Centered variables become Node Centered
- Node Centered variables become Face Centered
- An error is raised for edge centered variables
Data array or dataset? We load in datasets more often than anything else, right?
@philipc2
Continuing one of my comments above, we should create a
UxDataArray.get_dual()
method that keeps the data stored under the Data Array, but swaps the mapping such that:
- Face Centered variables become Node Centered
- Node Centered variables become Face Centered
- An error is raised for edge centered variables
Data array or dataset? We load in datasets more often than anything else, right?
I would suggest making a DataArray implementation (i.e. for a single data variable), and then also create a Dataset version. The user should be able to call either.
I believe edge-centered data should actually remain the same mapping in the both the dual & primal grids, since the new edge will intersect the original one.
Continuing one of my comments above, we should create a
UxDataArray.get_dual()
method that keeps the data stored under the Data Array, but swaps the mapping such that:
- Face Centered variables become Node Centered
- Node Centered variables become Face Centered
- An error is raised for edge centered variables
Data array or dataset? We load in datasets more often than anything else, right?
I would suggest making a DataArray implementation (i.e. for a single data variable), and then also create a Dataset version. The user should be able to call either.
I believe edge-centered data should actually remain the same mapping in the both the dual & primal grids, since the new edge will intersect the original one.
Not if the mesh has holes, then there will be less n_edges
.
@philipc2 This is ready for review, especially the notebook I put together would be great to have some feedback on.
Left an initial notebook review. Will give it a deeper look through tomorrow.
Closes #825
Overview
Constructs the dual mesh of a grid using
face_centers
andnode_face_connectivity
Expected Usage
PR Checklist
General
Testing
Documentation
_
) and have been added todocs/internal_api/index.rst
docs/user_api/index.rst