Integrate time coordinate with mobility functions #92
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR does the time integration for the mobility functions (relates to #75).
We adopt the same syntax as the section cuts, and simply offer both a
basevalues
andbasevalues_idx
input option to set the base maps by either their time, or time index. The same is offered forwindow
andwindow_idx
where the time lag over which mobility functions are computed can be set by either a dimensional value or value representing number of indices.The dimension of the returned object from the mobility functions should be flexible, so it will correspond to the first dimension of the 3-D xarray (if provided). This would allow someone to apply these methods to any arbitrary model output or input data. Overall a lot of input type handing and conversion goes on to accept inputs that are lists of arrays, or 3-D arrays (and xarray counterparts).
The
channel_presence
function has also been updated to keep track of dimensions and accept a wider set of input types.Tests and doc-strings have been updated to reflect changes, and an example has been added to the main page of the mobility API documentation as the computation required to generate a bunch of masks for each individual function docstring seemed excessive. For the singular example we compute land masks and channel masks for 10 of the
golfcube
time slices - I don't think this is too excessive for the docs build, but we can scale that back a bit if needed.of note: the masking functionality preserves the time dimension when using
__init__
pathways but not via the static methods, this has been noted in #75 and will be the subject of a future PR. Mobility calculation using the_idx
inputs will still work if the time dimension is messed up.edit: additional documentation addresses #29
old notes
This PR will eventually fully integrate the time coordinate with the mobility functions...
to do
basevalues
,basevalues_idx
,window
,window_idx
)