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

scikit linear regression_model, log-scale depths, wet-dry node handling #74

Closed
wants to merge 77 commits into from

Conversation

WPringle
Copy link
Contributor

@WPringle WPringle commented Feb 16, 2022

  • kwarg entry into surrogate from training function
  • show use of LassoCV model in the example
  • kwarg entry for conversion from log scale in validation and percentile outputs
  • kwarg entry for conversion from depths to elevations in validation and percentile outputs
  • analysis of depths in log scale to preserve positivity in the actual surrogate (instead of post-processing).
  • handling sometimes wet-sometimes dry nodes (extrapolation of nearby wet elevations to the dry node considering hydraulic friction loss)
  • subsetting by storm wind swath option added
  • sparse quadrature and user-defined options for quadrature order and quadrature rule

…he runs, change normalized bias/mean error to dimensional one
…ition as this seems to be faster and can handle larger datasets. Switched matrix order for the KL mode to avoid transposes and be consistent with the sklearn output.
@WPringle WPringle changed the title choose sciki linear regression_model for surrogate training scikit linear regression_model, log-scale depths, wet-dry node handling Feb 23, 2022
WPringle and others added 22 commits February 22, 2022 20:06
… height of surrogte KL fit plot where required
…e to a small constant null depth value which was negatively affecting the surrogate generation. Adjusting some validation plotting axis and colormap limits
* use `gartersnake`

* update build system

* update build system

* update build system

* update build system

* update build system

* update Python testing version
@WPringle
Copy link
Contributor Author

@zacharyburnettNOAA This branch is working with storm events v1.2.5 and all the uses that I have (making peturbed tracks and doing the KLPC analysis). Can we merge this in/make a release for this before upgrade to new storm events API?

@WPringle
Copy link
Contributor Author

WPringle commented Mar 11, 2022

@ghost
Copy link

ghost commented Mar 11, 2022

@WPringle that's a great idea, I agree with that

sorry I made so many API changes, I wanted to include all of the other unused ATCF fields and I got carried away

WPringle and others added 2 commits March 13, 2022 15:49
…tion within the given fraction of the distribution
* use new `StormEvents` API

* install wheel first

* install PROJ

* linting step

* build PROJ

* build PROJ

* build PROJ

* build PROJ

* fix workflows

* fix test files

* skip test that hangs

* fix original file test

* change original track handling (write to file first and then read from threads)

* update workflow names

* we no longer need to write pickles to a temporary file if the track object already exists in memory

* revert import change
@ghost ghost changed the base branch from main to release/v0.8.x March 14, 2022 14:26
@ghost
Copy link

ghost commented Mar 14, 2022

@WPringle I've made a new branch release/v0.8.x that should be an isolated place to use the old stormevents API until these changes are finalized, and made a pull request #79 that applies the API updates to this branch specifically (for merging these changes into v0.9.x)

…e_stormevents

# Conflicts:
#	ensembleperturbation/perturbation/atcf.py
#	setup.cfg
@ghost ghost changed the base branch from release/v0.8.x to main March 14, 2022 14:57
@WPringle
Copy link
Contributor Author

@zacharyburnettNOAA Thanks that sounds good. So do you want to try and update this branch with the base branch (v0.8.x) and merge this PR in before then updating main to v0.9.x?

@ghost
Copy link

ghost commented Mar 16, 2022

yes, I think it's a good idea to freeze what we have here so far (with the old API) to the v0.8.x branch and tag it there, and then merge in the new API changes. I will do that now

@ghost
Copy link

ghost commented Mar 16, 2022

@WPringle I've frozen these commits to a new tag v0.8.1 in the release https://github.com/noaa-ocs-modeling/EnsemblePerturbation/releases/tag/v0.8.1, that should be backward-compatible with the old API.

Now I will go ahead and merge the new API changes into this branch using #79, unless you have any objections to that

@WPringle
Copy link
Contributor Author

WPringle commented Mar 16, 2022

@zacharyburnettNOAA That's good yep! I'll go ahead and use this new version and see if working OK.
But I think we will need to work on the stormevents a bit more, especially for treating the advisories, breaking them up into individual forecasts instead of having them all squashed together.

@codecov-commenter
Copy link

codecov-commenter commented Mar 16, 2022

Codecov Report

Merging #74 (843b433) into main (57ffd09) will not change coverage.
The diff coverage is 0.00%.

@@           Coverage Diff           @@
##             main      #74   +/-   ##
=======================================
  Coverage   30.69%   30.69%           
=======================================
  Files          25       25           
  Lines        2926     2926           
=======================================
  Hits          898      898           
  Misses       2028     2028           
Impacted Files Coverage Δ
ensembleperturbation/client/perturb_tracks.py 0.00% <0.00%> (ø)
ensembleperturbation/parsing/adcirc.py 47.54% <0.00%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 57ffd09...843b433. Read the comment docs.

@WPringle
Copy link
Contributor Author

WPringle commented Mar 16, 2022

@zacharyburnettNOAA I'm noticing some changes in the column spacings and the forecast times are not being entered in correctly. The fort.22 columns need to be formatted exactly.

NEW: AL, 06, 2018091106, , BEST, 0,260N, 632W, 115
OLD: AL, 06, 2018091106, , BEST, 0, 260N, 632W, 115

NEW: AL, 06, 2018091106, , BEST, 0 - This zero should update along forecast but is all zeros.

@ghost
Copy link

ghost commented Mar 17, 2022

-AL, 06, 2018091106, , BEST, 0,260N, 632W, 115
+AL, 06, 2018091106, , BEST, 0, 260N, 632W, 115

Ok, I so latitude should be a 4-digit field (including N / S) and longitude should be 5 digits.

NEW: AL, 06, 2018091106, , BEST, 0 - This zero should update along forecast but is all zeros.

The specification says it should be "0 for best track":

TAU - forecast period: -24 through 240 hours, 0 for best-track, negative taus used for CARQ and WRNG records.

but I think that might be wrong because previously we were outputting positive forecast hours and worked. I will add the hours back in.

@WPringle
Copy link
Contributor Author

```diff
-AL, 06, 2018091106, , BEST, 0,260N, 632W, 115
+AL, 06, 2018091106, , BEST, 0, 260N, 632W, 115

Ok, I so latitude should be a 4-digit field (including N / S) and longitude should be 5 digits.

NEW: AL, 06, 2018091106, , BEST, 0 - This zero should update along forecast but is all zeros.

The specification says it should be "0 for best track":

TAU - forecast period: -24 through 240 hours, 0 for best-track, negative taus used for CARQ and WRNG records.

but I think that might be wrong because previously we were outputting positive forecast hours and worked. I will add the hours back in.

@zacharyburnettNOAA Yes you're right about the BEST track actually should be zero. As long as behavior is like original ATCF similar below then that will be great!

  • BEST track datetime = valid time, then the forecast hour = 0
  • OCFL (or other one forecast records), date time = initial time of forecast, then have non-zero forecast hours.

@WPringle
Copy link
Contributor Author

@zacharyburnettNOAA I forgot, can this PR be closed?

@ghost
Copy link

ghost commented Apr 27, 2022

@zacharyburnettNOAA I forgot, can this PR be closed?

sure thing, I will merge this into main

# Conflicts:
#	.github/workflows/build.yml
#	.github/workflows/tests.yml
#	ensembleperturbation/parsing/adcirc.py
#	ensembleperturbation/perturbation/atcf.py
#	ensembleperturbation/plotting/nodes.py
#	ensembleperturbation/uncertainty_quantification/surrogate.py
#	setup.cfg
#	setup.py
#	tests/data/reference/test_combine_outputs/fort.63.nc
#	tests/data/reference/test_combine_outputs/fort.64.nc
#	tests/data/reference/test_combine_outputs/maxele.63.nc
#	tests/data/reference/test_combine_outputs/maxvel.63.nc
#	tests/data/reference/test_monovariate_besttrack_ensemble/original.22
#	tests/data/reference/test_monovariate_besttrack_ensemble/vortex_1_variable_random_1.22
#	tests/data/reference/test_monovariate_besttrack_ensemble/vortex_1_variable_random_2.22
#	tests/data/reference/test_monovariate_besttrack_ensemble/vortex_1_variable_random_3.22
#	tests/data/reference/test_monovariate_besttrack_ensemble/vortex_1_variable_random_4.22
#	tests/data/reference/test_monovariate_besttrack_ensemble/vortex_1_variable_random_5.22
#	tests/data/reference/test_monovariate_besttrack_ensemble/vortex_1_variable_random_6.22
#	tests/data/reference/test_monovariate_besttrack_ensemble/vortex_1_variable_random_7.22
#	tests/data/reference/test_monovariate_besttrack_ensemble/vortex_1_variable_random_8.22
#	tests/data/reference/test_multivariate_besttrack_ensemble/original.22
#	tests/data/reference/test_multivariate_besttrack_ensemble/vortex_4_variable_random_1.22
#	tests/data/reference/test_multivariate_besttrack_ensemble/vortex_4_variable_random_2.22
#	tests/data/reference/test_multivariate_besttrack_ensemble/vortex_4_variable_random_3.22
#	tests/data/reference/test_spatial_perturbations/original.22
#	tests/data/reference/test_spatial_perturbations/original.json
#	tests/data/reference/test_spatial_perturbations/vortex_1_variable_random_1.22
#	tests/data/reference/test_spatial_perturbations/vortex_1_variable_random_1.json
#	tests/data/reference/test_spatial_perturbations/vortex_1_variable_random_2.22
#	tests/data/reference/test_spatial_perturbations/vortex_1_variable_random_2.json
#	tests/data/reference/test_spatial_perturbations/vortex_1_variable_random_3.22
#	tests/data/reference/test_spatial_perturbations/vortex_1_variable_random_3.json
#	tests/data/reference/test_spatial_perturbations/vortex_1_variable_random_4.22
#	tests/data/reference/test_spatial_perturbations/vortex_1_variable_random_4.json
#	tests/test_track_ensemble.py
@ghost
Copy link

ghost commented Apr 27, 2022

ok, I've merged the release/v0.8.x branch into mainso are the changes in this branch also important?

@WPringle
Copy link
Contributor Author

@zacharyburnettNOAA Thanks for the merge, of the v0.8.x.
I think we should delete this PR because all the changes in that branch were in here.

@WPringle
Copy link
Contributor Author

WPringle commented Apr 27, 2022

@zacharyburnettNOAA I mean whichever is compatible with newer StormEvents according to the two file changes here.

@ghost ghost closed this Apr 27, 2022
This pull request was closed.
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.

3 participants