[wip] SPH field refactor / kernel pixelizer

#2382 Declined
Repository
ngoldbaum
Branch
yt
Repository
yt_analysis
Branch
yt
Author
  1. Nathan Goldbaum
Reviewers
Description

This is a re-issue of PR 2127. I'm issuing it now so @Bili Dong has a reference to build off of.

Here's the description from the original pull request:

This adds an initial implementation of a smoothing kernel for pixelizing SPH fields and changes the field API for SPH data so 'gas' fields are returns at the locations of SPH particles. This code is still in implementation stage.

Update 1: Initial work to integrate the pixelizer into the rest of yt Update 2: Added slice pixelizer, finished integrating into SlicePlot Update 3: projections work, lots of work to get local fields fully working Update 4 all data objects fully working. Merged with Meagan's bitmask index work.

TODO:

  • fields that need spatial derivatives
  • YTEP

Comments (18)

      1. Bili Dong

        My analysis above is wrong. Currently I can only tell that the error raises when pos and hsml have different dtypes. When they are the same, even when both are np.float32, it works. I'm referring to pos and hsml in this line.

              1. Bili Dong

                Yes, it works. I cannot come up with a better solution. Just wondering if you know the mechanism why there would be errors at the first place?

                1. Nathan Goldbaum author

                  I think it's a limitation of cython's fused types. We can make a function take two arrays with dtype floating, but then both arrays must have the same dtype. It doesn't combinatorially generate code for the case when both arrays have different dtypes that are members of the cython.floating fused type.

    1. Bili Dong

      It still feels weird to me that although _yield_coordinates and _yield_smoothing_length's definitions look very similar, they yield different dtypes (pos is float64, while hsml is float32).

      1. Bili Dong

        I've been looking at the source code for a while. I feel I don't have enough knowledge to work on this. One strange thing I find is that while ds.find_max(('gas', 'density')) raises error, ds.all_data()[('gas', 'density')] doesn't. Is this expected?

        1. Nathan Goldbaum author

          Yes, the former is indirectly invoking a derived quantity, the latter isn't. Right now derived quantities are hitting a code path that assumes you can generate coordinates for a mesh that doesn't exist anymore now that we've removed the mesh. The fix is probably just to short-circuit that but I haven't sat down and tried to figure out how to do that yet.

          Don't waste too much time on fixing derived quantities, I am planning to do it soon and am probably more familiar with that part of the codebase.

          1. Bili Dong

            Thanks for the explanation! I'm trying to make the demeshening code work with Trident and this is one road block. I'll continue the testing once this is fixed.

            1. MattT

              I took a quick look, and I think the issue is with get_position_fields in derived_quantities.py, which is somehow not picking up that the gas density is no longer a particle field.