yt-project / yt

Main yt repository
http://yt-project.org
Other
460 stars 276 forks source link

Include particles in the neighboring blocks for nearest neighbor particle deposition? #1186

Open yt-fido opened 8 years ago

yt-fido commented 8 years ago

Originally reported by: Yi-Hao Chen (Bitbucket: yihaochen, GitHub: yihaochen)


As I understand, the current nearest neighbor particle deposition function takes only the particle with in a block and assign the values of each cell by the nearest particle. However, it does not take the particles in the adjacent blocks into account. Thus it results in sharp boundaries between the blocks in the deposited field. It also gives empty blocks if there is no particle inside them, even though there are some particles just next to the wall.

I am interested in implementing a more flexible nearest neighbor deposition that takes at least the particles in the surrounding blocks into consideration. I have thought about some possible methods. But due to my unfamiliarity with the data structure, I am not sure if they are really possible. It would be great to have your suggestions. Thanks!

  1. Pass more particles into the deposition function in Dataset.add_deposited_particle_field. Instead of using pos = data[ptype, "particle_position"], I can include all nearby particles by using something like pos = data.ds.all_data()[ptype, "particle_position"][mask] where mask filters out the needed particles by specifying the boundaries. However, since data is not necessary a grid, it might have some problems.

  2. Use validator to force data to be a grid. Then I can include particles in the surrounding blocks. I am not sure if yt loaded the indices of surrounding blocks, but it seems that the information is readily available in my FLASH plot files.

  3. Force data to include guard cells. I don't really know how guard cells work in yt. But in principle I can stored the deposited field and distance information in the guard cells, and compare them with the grid data to decide which value I want to keep. It might be too complicated though...

--

[Updates] Thanks to Nathan pointing out some similar issues (917, 918) and discussion.


yt-fido commented 8 years ago

Original comment by Nathan Goldbaum (Bitbucket: ngoldbaum, GitHub: ngoldbaum):


Since this will be a new feature, I'm going to punt on resolving this for the 3.3 release.

yt-fido commented 8 years ago

Original comment by Nathan Goldbaum (Bitbucket: ngoldbaum, GitHub: ngoldbaum):


@yihaochen produced the following test script during a slack discussion:

http://paste.yt-project.org/show/6313/

When run with the following patch:

#!python

diff -r 9c26b9791511 yt/data_objects/static_output.py
--- a/yt/data_objects/static_output.py  Sun Mar 13 13:22:41 2016 -0500
+++ b/yt/data_objects/static_output.py  Mon Mar 14 14:17:21 2016 -0500
@@ -1081,7 +1081,7 @@ class Dataset(object):
             function=_deposit_field,
             units=units,
             take_log=take_log,
-            validators=[ValidateSpatial()])
+            validators=[ValidateSpatial(1)])
         return ("deposit", field_name)

     def add_smoothed_particle_field(self, smooth_field, method="volume_weighted",

Produces the following error:

http://paste.yt-project.org/show/6314/

yt-fido commented 8 years ago

Original comment by Nathan Goldbaum (Bitbucket: ngoldbaum, GitHub: ngoldbaum):


ping @MatthewTurk as requested on slack

yt-fido commented 8 years ago

Original comment by Nathan Goldbaum (Bitbucket: ngoldbaum, GitHub: ngoldbaum):


It was, but the conversation will be limited to the issue.

yt-fido commented 8 years ago

Original comment by Yi-Hao Chen (Bitbucket: yihaochen, GitHub: yihaochen):


I thought the issue will be automatically posted to yt-dev list. Wasn't it?

yt-fido commented 8 years ago

Original comment by Nathan Goldbaum (Bitbucket: ngoldbaum, GitHub: ngoldbaum):


Also you might want to raise this on the yt-dev mailing list - more people will see it.

yt-fido commented 8 years ago

Original comment by Nathan Goldbaum (Bitbucket: ngoldbaum, GitHub: ngoldbaum):


@atmyers thought about this a bit at one point.