Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Gb/bias nc #181

Merged
merged 15 commits into from
Dec 18, 2023
Merged

Gb/bias nc #181

merged 15 commits into from
Dec 18, 2023

Conversation

grantbuster
Copy link
Member

@grantbuster grantbuster commented Dec 8, 2023

@bnb32: refactor for sub-grid aggregation for bias calculations, topo extractions, and a feature to allow the baseline input file in bias calculation to be .nc (e.g., ERA)

@grantbuster grantbuster marked this pull request as ready for review December 8, 2023 18:18
@@ -275,6 +261,26 @@ def prep_var_lists(self, variables):
logger.warning(msg)
warn(msg)

@staticmethod
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you went on a clean up spree huh? nice!

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Haha yeah i thought some of the sphinx issues were being caused by these special imports that weren't being installed... That's not the issue but oh well now it's cleaner.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

and it did turn out to be some weird import thing!

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Haha yeah just not the few that i tried 🤦

@@ -281,7 +281,9 @@ def extract_feature(cls,
time_slice)

else:
msg = f'{feature} cannot be extracted from source data.'
available = [str(var) for var in handle.variables]
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we can use cls.get_handle_features here, for both nc and h5

@@ -179,8 +185,7 @@ def __init__(self,
def source_data(self):
"""Get the 1D array of source data from the exo_source_h5"""

def get_cache_file(self, feature, s_enhance, t_enhance, s_agg_factor,
t_agg_factor):
def get_cache_file(self, feature, s_enhance, t_enhance, t_agg_factor):
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

dont we want the cache identified by spatial agg factor?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah I actually removed the s_agg_factor from the whole module altogether because for the topo aggregation "factor" it's now determined by the actual pixel mapping.

self.bias_gid_raster = np.arange(lats.size)
self.bias_gid_raster = self.bias_gid_raster.reshape(raster_shape)

self.nn_dist, self.nn_ind = self.bias_tree.query(
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So it looks like theres no spatial agg being done anymore for bc? I think circular agg is still better than none

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah so there are two options with low->high res mapping:

  1. Tree(high_res).query(low_res, k=1000)
  2. Tree(low_res).query(high_res, k=1)

We were previously doing 1 which maps circles of high-res pixels to each low-res centroid which is fine but double counts some stuff in the circle overlaps.

I moved the bias calc and topo exo extraction to 2 which takes every high-res pixel and assigns to nearest low res pixel. This basically makes a sudoku style sub-grid aggregation. The mapping happens in the two places linked below (for bias calc, exo happens somewhere else).

I checked the difference between 1 and 2 in the bias calc and the differences were negligible in the bulk of the extent with differences 1-5% at the borders of the extent.

The biggest caveat here is that the high-resolution must be higher resolution than the low-resolution data for the mapping to work. The main failure mode is if a low-res pixel doesn't get assigned a unique high-res pixel. I put in a method to gap fill this but it's not great.

https://github.com/NREL/sup3r/pull/181/files/1fcd177bdca46eae74a3ecbd9052d92a02ee54a7#diff-97f5ed5dfa872e6781c2c5bc1de5c1abb705fd0302767321c0ff73d63fa1c140R291-R314

https://github.com/NREL/sup3r/pull/181/files/#diff-97f5ed5dfa872e6781c2c5bc1de5c1abb705fd0302767321c0ff73d63fa1c140R949

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, missed the tree being built on low_res. Good approach!

@grantbuster grantbuster merged commit 6d0f100 into main Dec 18, 2023
8 checks passed
@grantbuster grantbuster deleted the gb/bias_nc branch December 18, 2023 16:18
github-actions bot pushed a commit that referenced this pull request Dec 18, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants