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

Trying to reorder constituents as in ‘OrderCnstit’ #91

Closed
aaretxabaleta-usgs opened this issue Mar 7, 2021 · 5 comments · Fixed by #96
Closed

Trying to reorder constituents as in ‘OrderCnstit’ #91

aaretxabaleta-usgs opened this issue Mar 7, 2021 · 5 comments · Fixed by #96

Comments

@aaretxabaleta-usgs
Copy link

As @rsignell-usgs mentioned in a previous issue, we are trying to analyze the tides at each grid cell in a numerical model solution. We run utide for each grid point but the order of the constituents can be different for each grid point. In the Matlab code, there is the option ‘OrderCnstit’ that allows passing a specified order of constituents when constit is not set to 'auto'. Is there a similar reordering for the python version?

@efiring
Copy link
Collaborator

efiring commented Mar 7, 2021

Yes, there are some options that have not yet had their names pythonized and added to the docstring, and this is one. It's all lower case: "ordercnstit", and it can be None, "frq", "snr", or a list of constituent names like ["M2", "S2"].

However... if I were doing this calculation for numerical model output, I would not use UTide directly; I would just extract and vectorize the underlying least-squares calculation, assuming all you want is the coefficients and possibly the series reconstructed from them. Ideally, I would go ahead and package this vectorized short version as a separate function pair in UTide. It's just among the many things I haven't gotten around to doing, like proceeding with more pythonization and cleanup of the codebase.

@ocefpaf
Copy link
Collaborator

ocefpaf commented Mar 8, 2021

@efiring I'm not sure we are really allowing that keyword. We have strict=True hardcoded in Bunch and that throws an error when an unexpected key is used. See #93

@efiring
Copy link
Collaborator

efiring commented Mar 8, 2021

OK, I will make a PR to add it properly.

@ocefpaf
Copy link
Collaborator

ocefpaf commented Mar 8, 2021

BTW, I'm moving our tests to GitHub Actions. PR soon... (Travis-CI has become unbearable for OSS projects lately.)

@efiring
Copy link
Collaborator

efiring commented Mar 8, 2021

It turns out, with simple testing, that this ordering business opens up quite a rats' nest of interacting options and confusing code. This may take some time to sort out.

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 a pull request may close this issue.

3 participants