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

Export standard deviation to pandas DataFrames and AstroPy QTables #4410

Merged
merged 5 commits into from
Apr 13, 2023

Conversation

jzuhone
Copy link
Contributor

@jzuhone jzuhone commented Apr 10, 2023

PR Summary

Profiles in yt can already export data to pandas DataFrames and AstroPy QTables. This PR adds the capability to optionally export the standard deviation of the profile to the data frame or table. Docs and tests are added.

PR Checklist

  • New features are documented, with docstrings and narrative docs
  • Adds a test for any bugs fixed. Adds tests for new features.

@jzuhone jzuhone added the enhancement Making something better label Apr 10, 2023
)
assert (
prof.standard_deviation[("gas", "density")].units
== YTArray.from_astropy(at3["density_stddev"]).units
Copy link
Member

Choose a reason for hiding this comment

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

shouldn't the field type also be included in the key ("gas_density_stddev" instead of "density_stddev") ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@neutrinoceros so the field type is not included already even when we do not include the standard deviation (I don't remember why). So you would access the mean of the profile using at3["density"]

Copy link
Member

Choose a reason for hiding this comment

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

ok, at least it's consistent.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We could add the field type, but I'm a bit leery of using _ to connect them since _ could appear in field type strings (and does appear in field name strings), making parsing a bit difficult in some cases.

Is there another sensible character to use to indicate the breaking of the field type and name? Maybe even , is ok? I don't know (cc @matthewturk)

Copy link
Member

Choose a reason for hiding this comment

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

I guess that would be a breaking change, so I'm actually -1 on this. Let's keep it as is for now.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ok then, this is ready to go.

chrishavlin
chrishavlin previously approved these changes Apr 12, 2023
Copy link
Contributor

@chrishavlin chrishavlin left a comment

Choose a reason for hiding this comment

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

Looks good, caught a small typo in the new docstring entries

yt/data_objects/profiles.py Outdated Show resolved Hide resolved
yt/data_objects/profiles.py Outdated Show resolved Hide resolved
Co-authored-by: Chris Havlin <chris.havlin@gmail.com>
Co-authored-by: Chris Havlin <chris.havlin@gmail.com>
@jzuhone
Copy link
Contributor Author

jzuhone commented Apr 12, 2023

Thanks @chrishavlin!

@neutrinoceros neutrinoceros merged commit 4c13634 into yt-project:main Apr 13, 2023
@jzuhone jzuhone deleted the export_stddev branch April 14, 2023 10:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Making something better
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants