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

[frontend] Adaptahop support #2385

Merged
merged 40 commits into from
Feb 6, 2020
Merged

Conversation

cphyc
Copy link
Member

@cphyc cphyc commented Dec 12, 2019

PR Summary

This adds support for the AdaptaHOP halo finder.

PR Checklist

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

@cphyc cphyc requested a review from brittonsmith December 12, 2019 17:25
This was causing any `.halo` method to be overriden in
`._setup_classes` by a `.halo` method that would return a
`GadgetFOFHaloContainer` object.
@matthewturk
Copy link
Member

The test failure seems a bit odd -- it says get_halo is not defined. Is that the case? If so, we might need to use a different test.

@cphyc
Copy link
Member Author

cphyc commented Dec 16, 2019

The error was mine, I did not define get_halo but halo instead.
This should be fixed now.

In Python < 3.6, dicts are not ordered so that iterating over key, values is not predictible. This caused the position to be filled with garbage (depending on the fields being read from disk) and then rejected by the selector, so that the shape of the data was depending on what was being read from disk (which influenced the order of the dictionary, which changed which garbage ends up in x, y, z).
@matthewturk
Copy link
Member

The appveryor error was fixed in #2395. So I think this is ready for review and acceptance.

Copy link
Member

@matthewturk matthewturk 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 -- may have more comments but I think this is good to go! Thanks!

@@ -1954,7 +1954,7 @@ def __init__(self, center, ds, field_parameters = None, data_source = None):
self.coords = None
self._grids = None

def cut_region(self, field_cuts, field_parameters=None):
def cut_region(self, field_cuts, field_parameters=None, locals={}):
Copy link
Member

Choose a reason for hiding this comment

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

Interesting addition -- good idea.

if pcount == 0:
continue
pos = self._get_particle_positions()
yield ptype, (pos[:, i] for i in range(3))
Copy link
Member

Choose a reason for hiding this comment

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

Do we want this generator or should it be a list?

@codecov
Copy link

codecov bot commented Jan 21, 2020

Codecov Report

Merging #2385 into master will increase coverage by 21.66%.
The diff coverage is 92.42%.

Impacted file tree graph

@@             Coverage Diff             @@
##           master    #2385       +/-   ##
===========================================
+ Coverage   49.16%   70.83%   +21.66%     
===========================================
  Files         258      262        +4     
  Lines       46785    47176      +391     
  Branches     8196     8264       +68     
===========================================
+ Hits        23002    33417    +10415     
+ Misses      22330    11714    -10616     
- Partials     1453     2045      +592
Impacted Files Coverage Δ
yt/frontends/ramses/particle_handlers.py 85.45% <ø> (+54.54%) ⬆️
yt/frontends/adaptahop/fields.py 100% <100%> (ø)
yt/frontends/gadget_fof/data_structures.py 83.72% <100%> (+60.58%) ⬆️
yt/frontends/adaptahop/definitions.py 100% <100%> (ø)
yt/data_objects/selection_data_containers.py 89.6% <66.66%> (+0.31%) ⬆️
yt/data_objects/data_containers.py 82.48% <66.66%> (+2.99%) ⬆️
yt/frontends/adaptahop/io.py 92.09% <92.09%> (ø)
yt/frontends/adaptahop/data_structures.py 93.38% <93.38%> (ø)
yt/visualization/color_maps.py 84.09% <0%> (-1.3%) ⬇️
... and 157 more

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 23d1e5a...d9e5752. Read the comment docs.

Comment on lines +8 to +14
#-----------------------------------------------------------------------------
# Copyright (c) 2013, yt Development Team.
#
# Distributed under the terms of the Modified BSD License.
#
# The full license is in the file COPYING.txt, distributed with this software.
#-----------------------------------------------------------------------------
Copy link
Member

Choose a reason for hiding this comment

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

I think we're removing the copyright comment blocks now, right?

Copy link
Member

Choose a reason for hiding this comment

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

nevermind I realized that your PRs removing them were for yt-4.0.

Copy link
Member Author

Choose a reason for hiding this comment

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

That's actually a fair comment since #2396 has already been accepted. Either (1) I remove the copyright notices here, (2) I reopen a PR on yt-4 once #1838 has been merged in, (3) I rebase this PR on yt-4 without the copyright notices.

What do you think?

Copy link
Member

Choose a reason for hiding this comment

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

I think (2) seems like the best option. There are other frontends that have been added to master that aren't on the 4.0 branch, so they'll need to be cleaned up too. I think it makes sense to do a cleanup of all of it once #1838 is in.

Copy link
Member Author

Choose a reason for hiding this comment

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

Fair enough! For reference, I made a mistake, the merge PR is #2172 (so that it appears in its log).

Copy link
Member

Choose a reason for hiding this comment

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

Ha, clearly I haven't had my ☕️ yet!

@munkm
Copy link
Member

munkm commented Jan 21, 2020

Hey @brittonsmith do you want to take a look over this PR?

@brittonsmith
Copy link
Member

Hi everyone, especially Corentin! I'm so sorry taking so long to review this PR. December and January have been extremely busy months. I've got a major proposal deadline at the end of this week, but I am committing to reviewing this by the end of next week. My apologies for the delay, but thanks for your patience!

Copy link
Member

@brittonsmith brittonsmith left a comment

Choose a reason for hiding this comment

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

Sorry again for taking so long to review this. It looks great to me. I only had a few pretty minor comments.

@munkm
Copy link
Member

munkm commented Feb 5, 2020

The appveyor issues popping up here seem to be the same numpy issues reported in Slack earlier today by @neutrinoceros, and are unrelated to this PR.

Copy link
Member

@brittonsmith brittonsmith left a comment

Choose a reason for hiding this comment

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

Ok, this is good to go by me. Great work here.

Should we wait until the appveyor tests are fixed or just go ahead and merge?

@matthewturk
Copy link
Member

@munkm If you think it's OK to include, with the appveyor failure, I say hit the merge button.

@munkm munkm merged commit 07a15fe into yt-project:master Feb 6, 2020
@cphyc cphyc deleted the adaptahop-support branch January 13, 2021 11:18
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.

5 participants