-
Notifications
You must be signed in to change notification settings - Fork 77
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
Generalize echopype software provenance and apply to Sv and MVBS #621
Conversation
for more information, see https://pre-commit.ci
for more information, see https://pre-commit.ci
Codecov Report
@@ Coverage Diff @@
## dev #621 +/- ##
==========================================
- Coverage 78.75% 69.57% -9.18%
==========================================
Files 42 37 -5
Lines 3784 3744 -40
==========================================
- Hits 2980 2605 -375
- Misses 804 1139 +335
Flags with carried forward coverage won't be shown. Click here to find out more.
📣 Codecov can now indicate which changes are the most critical in Pull Requests. Learn more |
} | ||
if source_files: | ||
# TODO: src_filenames will be replaced with a new variable, source_filenames | ||
# Also, come to think of it, source files is not "echopype provenance" info per se |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you mean that source_files is part of the convention and not from echopype? Just wanted to make sure I understand this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What I meant with "source files is not "echopype provenance" info per se" was that all the other attributes I've included in echopype_prov_attrs
are about the echopype software itself, but source files is not. Though, come to think of it, strictly speaking, conversion_time
is not either .... Hmm. We could rename echopype_prov_attrs
to something more general. Its scope is the software used (name & version) and basic info about its application (timestamp when it was run, and input files used -- though the latter will be moved to a variable and will no longer be an attribute)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking at this again and seeing how processing_function is currently separately done in calibrate.api._compute_cal, I wonder if we could rename this to echopype_ver_time_files_prov
so that it is clear what this function does, for when we come back to provenance in the future.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, sounds good. It sounds like you're also saying that we keep the source_files provenance functionality in this function, even though it'll be changed to add xarray variables rather than an attribute. Correct? I haven't thought through the consequences of doing that for this function, given that echopype_prov_attrs
currently just populates a dict and returns it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It sounds like you're also saying that we keep the source_files provenance functionality in this function, even though it'll be changed to add xarray variables rather than an attribute. Correct?
I didn't think that far... ha. I think you are right that since it will be a data variable not an attribute, it should not be here. In that case, the function name would become echopype_ver_time_prov
.
@leewujung this is what I was referring to. |
TODO: Add software provenance attributes to |
TODO: For EK80, add |
Yes please pass these to MVBS also, as part of the chain of provenance (is there a specific term for this chain?). |
for more information, see https://pre-commit.ci
@leewujung I've pushed several commits that include multiple improvements, some of which are not about provenance per se.
I decided not to try to implement "provenance chain", where, say, parameters used in computing Sv are passed downstream to MVBS. I think that's a larger topic. Let's revisit it after 0.6.0 is out, at some point when we focus on provenance again. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I pushed a change to remove the unused datetime import since GH doesn't allow me to comment on unchanged code.
I added a few suggestions, but otherwise this looks ready to go!
FYI- I pondered a bit about the long_name
you added for Sv_noise
and Sv_corrected
, but decided that what you have is appropriate.
Thanks!
Great. And yeah, I struggled a bit with that.
Great! But since I've made some follow-up comments to your inline comments, I'll give you more time to react. Let's plan to merge today, if possible. |
I think I reacted to everything, haha. I can't wait to see this merged!! 😎 |
Thank you!! Merging now |
Addresses #618. Let's keep it as a draft PR for now, for discussion.
I've abstracted the assignment of the current
Provenance
software attributes into a function in the new moduleutils.prov.py
. This function now handles bothconversion_*
andprocessing_*
attributes in a single place. Also eliminated existing duplication of attribute assignments.Note the additional (not from the convention) global attribute I've added as a suggestion for Sv and MVBS:
processing_function
. It would allow us to record the actual function used.Doesn't address the move from
src_filenames
global attribute to asource_filenames
variable (#620)