length of octree and smoothed arrays
Hi All,
First, I'm on an updated yt 3.0 updated about 5 minutes ago. (hg id: ea182fc68fae (yt-3.0) tip)
This might be related to Matt's update on octree on June 8th (in response to the CIC stuff) that I don't quite understand, but I've run into the following issue highlighted in the example code:
http://paste.yt-project.org/show/4781/
Here, I create a fake data set (motivated by Nathan's shared notebook earlier this week), construct the octree, and then smooth the density onto a grid with:
density = ad["deposit","all_density"]
What I find is that the number of elements in the density array is not the same as the number of 0's (i.e Falses) in the generated octree (revealed by
saved["octree"]
in the above script). Nominally, I thought the smoothing happened onto the same octree mesh that I generate with ds.index.oct_handler.save_octree(). Is this not the case? Or, is there a way to make it the case in the order that I call things?
Thanks, desika
Hi Desika,
On Thu, Jun 12, 2014 at 12:04 PM, Desika Narayanan dnarayan@haverford.edu wrote:
Hi All,
First, I'm on an updated yt 3.0 updated about 5 minutes ago. (hg id: ea182fc68fae (yt-3.0) tip)
This might be related to Matt's update on octree on June 8th (in response to the CIC stuff) that I don't quite understand, but I've run into the following issue highlighted in the example code:
http://paste.yt-project.org/show/4781/
Here, I create a fake data set (motivated by Nathan's shared notebook earlier this week), construct the octree, and then smooth the density onto a grid with:
density = ad["deposit","all_density"]
What I find is that the number of elements in the density array is not the same as the number of 0's (i.e Falses) in the generated octree (revealed by
saved["octree"]
in the above script). Nominally, I thought the smoothing happened onto the same octree mesh that I generate with ds.index.oct_handler.save_octree(). Is this not the case? Or, is there a way to make it the case in the order that I call things?
No, it should all be the same. What're the values of:
saved["octree"].sum() saved["octree"].size ad["deposit", "all_density"].size
Thanks, desika
yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
Hi Matt,
Thanks - the numbers are the same as the length of the numbers of ones in saved['octree'], total sizes of octree and size of density array:
saved["octree"].sum() = 4681 saved["octree"].size = 37499 ad["deposit", "all_density"].size = 262144
On Thu, Jun 12, 2014 at 2:06 PM, Matthew Turk matthewturk@gmail.com wrote:
Hi Desika,
On Thu, Jun 12, 2014 at 12:04 PM, Desika Narayanan dnarayan@haverford.edu wrote:
Hi All,
First, I'm on an updated yt 3.0 updated about 5 minutes ago. (hg id: ea182fc68fae (yt-3.0) tip)
This might be related to Matt's update on octree on June 8th (in
response to
the CIC stuff) that I don't quite understand, but I've run into the following issue highlighted in the example code:
http://paste.yt-project.org/show/4781/
Here, I create a fake data set (motivated by Nathan's shared notebook earlier this week), construct the octree, and then smooth the density
onto a
grid with:
density = ad["deposit","all_density"]
What I find is that the number of elements in the density array is not
the
same as the number of 0's (i.e Falses) in the generated octree (revealed
by
saved["octree"]
in the above script). Nominally, I thought the smoothing happened onto
the
same octree mesh that I generate with ds.index.oct_handler.save_octree(). Is this not the case? Or, is there a way to make it the case in the
order
that I call things?
No, it should all be the same. What're the values of:
saved["octree"].sum() saved["octree"].size ad["deposit", "all_density"].size
Thanks, desika
yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
Hi Desika,
I actually can't get your script to run. Which changeset are you on?
-Matt
On Thu, Jun 12, 2014 at 12:13 PM, Desika Narayanan dnarayan@haverford.edu wrote:
Hi Matt,
Thanks - the numbers are the same as the length of the numbers of ones in saved['octree'], total sizes of octree and size of density array:
saved["octree"].sum() = 4681 saved["octree"].size = 37499 ad["deposit", "all_density"].size = 262144
On Thu, Jun 12, 2014 at 2:06 PM, Matthew Turk matthewturk@gmail.com wrote:
Hi Desika,
On Thu, Jun 12, 2014 at 12:04 PM, Desika Narayanan dnarayan@haverford.edu wrote:
Hi All,
First, I'm on an updated yt 3.0 updated about 5 minutes ago. (hg id: ea182fc68fae (yt-3.0) tip)
This might be related to Matt's update on octree on June 8th (in response to the CIC stuff) that I don't quite understand, but I've run into the following issue highlighted in the example code:
http://paste.yt-project.org/show/4781/
Here, I create a fake data set (motivated by Nathan's shared notebook earlier this week), construct the octree, and then smooth the density onto a grid with:
density = ad["deposit","all_density"]
What I find is that the number of elements in the density array is not the same as the number of 0's (i.e Falses) in the generated octree (revealed by
saved["octree"]
in the above script). Nominally, I thought the smoothing happened onto the same octree mesh that I generate with ds.index.oct_handler.save_octree(). Is this not the case? Or, is there a way to make it the case in the order that I call things?
No, it should all be the same. What're the values of:
saved["octree"].sum() saved["octree"].size ad["deposit", "all_density"].size
Thanks, desika
yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
Hi Matt,
I just did yt update very recently (like an hour ago). an hg id gives:
yt-hg desika$ hg id
ea182fc68fae (yt-3.0) tip
On Thu, Jun 12, 2014 at 2:28 PM, Matthew Turk matthewturk@gmail.com wrote:
Hi Desika,
I actually can't get your script to run. Which changeset are you on?
-Matt
On Thu, Jun 12, 2014 at 12:13 PM, Desika Narayanan dnarayan@haverford.edu wrote:
Hi Matt,
Thanks - the numbers are the same as the length of the numbers of ones in saved['octree'], total sizes of octree and size of density array:
saved["octree"].sum() = 4681 saved["octree"].size = 37499 ad["deposit", "all_density"].size = 262144
On Thu, Jun 12, 2014 at 2:06 PM, Matthew Turk matthewturk@gmail.com
wrote:
Hi Desika,
On Thu, Jun 12, 2014 at 12:04 PM, Desika Narayanan dnarayan@haverford.edu wrote:
Hi All,
First, I'm on an updated yt 3.0 updated about 5 minutes ago. (hg id: ea182fc68fae (yt-3.0) tip)
This might be related to Matt's update on octree on June 8th (in response to the CIC stuff) that I don't quite understand, but I've run into the following issue highlighted in the example code:
http://paste.yt-project.org/show/4781/
Here, I create a fake data set (motivated by Nathan's shared notebook earlier this week), construct the octree, and then smooth the density onto a grid with:
density = ad["deposit","all_density"]
What I find is that the number of elements in the density array is not the same as the number of 0's (i.e Falses) in the generated octree
(revealed
by
saved["octree"]
in the above script). Nominally, I thought the smoothing happened
onto
the same octree mesh that I generate with ds.index.oct_handler.save_octree(). Is this not the case? Or, is there a way to make it the case in the order that I call things?
No, it should all be the same. What're the values of:
saved["octree"].sum() saved["octree"].size ad["deposit", "all_density"].size
Thanks, desika
yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
Hi Desika,
Your particles are pretty randomly distributed, so it's refining everywhere up to a given level. Try changing to np.random.normal, but you might need to clip. There's also a factor of eight for leaf nodes, because a leaf node by default becomes eight cells.
http://paste.yt-project.org/show/4782/
This gives the results I was expecting. Do they look okay to you?
-Matt
On Thu, Jun 12, 2014 at 12:30 PM, Desika Narayanan dnarayan@haverford.edu wrote:
Hi Matt,
I just did yt update very recently (like an hour ago). an hg id gives:
yt-hg desika$ hg id
ea182fc68fae (yt-3.0) tip
On Thu, Jun 12, 2014 at 2:28 PM, Matthew Turk matthewturk@gmail.com wrote:
Hi Desika,
I actually can't get your script to run. Which changeset are you on?
-Matt
On Thu, Jun 12, 2014 at 12:13 PM, Desika Narayanan dnarayan@haverford.edu wrote:
Hi Matt,
Thanks - the numbers are the same as the length of the numbers of ones in saved['octree'], total sizes of octree and size of density array:
saved["octree"].sum() = 4681 saved["octree"].size = 37499 ad["deposit", "all_density"].size = 262144
On Thu, Jun 12, 2014 at 2:06 PM, Matthew Turk matthewturk@gmail.com wrote:
Hi Desika,
On Thu, Jun 12, 2014 at 12:04 PM, Desika Narayanan dnarayan@haverford.edu wrote:
Hi All,
First, I'm on an updated yt 3.0 updated about 5 minutes ago. (hg id: ea182fc68fae (yt-3.0) tip)
This might be related to Matt's update on octree on June 8th (in response to the CIC stuff) that I don't quite understand, but I've run into the following issue highlighted in the example code:
http://paste.yt-project.org/show/4781/
Here, I create a fake data set (motivated by Nathan's shared notebook earlier this week), construct the octree, and then smooth the density onto a grid with:
density = ad["deposit","all_density"]
What I find is that the number of elements in the density array is not the same as the number of 0's (i.e Falses) in the generated octree (revealed by
saved["octree"]
in the above script). Nominally, I thought the smoothing happened onto the same octree mesh that I generate with ds.index.oct_handler.save_octree(). Is this not the case? Or, is there a way to make it the case in the order that I call things?
No, it should all be the same. What're the values of:
saved["octree"].sum() saved["octree"].size ad["deposit", "all_density"].size
Thanks, desika
yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
Hi Matt,
Thanks - it's the factor of 8 that was throwing me off. Once I account for that, the numbers make sense.
thanks -desika
On Thu, Jun 12, 2014 at 2:38 PM, Matthew Turk matthewturk@gmail.com wrote:
Hi Desika,
Your particles are pretty randomly distributed, so it's refining everywhere up to a given level. Try changing to np.random.normal, but you might need to clip. There's also a factor of eight for leaf nodes, because a leaf node by default becomes eight cells.
http://paste.yt-project.org/show/4782/
This gives the results I was expecting. Do they look okay to you?
-Matt
On Thu, Jun 12, 2014 at 12:30 PM, Desika Narayanan dnarayan@haverford.edu wrote:
Hi Matt,
I just did yt update very recently (like an hour ago). an hg id gives:
yt-hg desika$ hg id
ea182fc68fae (yt-3.0) tip
On Thu, Jun 12, 2014 at 2:28 PM, Matthew Turk matthewturk@gmail.com
wrote:
Hi Desika,
I actually can't get your script to run. Which changeset are you on?
-Matt
On Thu, Jun 12, 2014 at 12:13 PM, Desika Narayanan dnarayan@haverford.edu wrote:
Hi Matt,
Thanks - the numbers are the same as the length of the numbers of ones in saved['octree'], total sizes of octree and size of density array:
saved["octree"].sum() = 4681 saved["octree"].size = 37499 ad["deposit", "all_density"].size = 262144
On Thu, Jun 12, 2014 at 2:06 PM, Matthew Turk matthewturk@gmail.com wrote:
Hi Desika,
On Thu, Jun 12, 2014 at 12:04 PM, Desika Narayanan dnarayan@haverford.edu wrote:
Hi All,
First, I'm on an updated yt 3.0 updated about 5 minutes ago. (hg
id:
ea182fc68fae (yt-3.0) tip)
This might be related to Matt's update on octree on June 8th (in response to the CIC stuff) that I don't quite understand, but I've run into the following issue highlighted in the example code:
http://paste.yt-project.org/show/4781/
Here, I create a fake data set (motivated by Nathan's shared
notebook
earlier this week), construct the octree, and then smooth the
density
onto a grid with:
>density = ad["deposit","all_density"]
What I find is that the number of elements in the density array is not the same as the number of 0's (i.e Falses) in the generated octree (revealed by
>saved["octree"]
in the above script). Nominally, I thought the smoothing happened onto the same octree mesh that I generate with ds.index.oct_handler.save_octree(). Is this not the case? Or, is there a way to make it the case in
the
order that I call things?
No, it should all be the same. What're the values of:
saved["octree"].sum() saved["octree"].size ad["deposit", "all_density"].size
Thanks, desika
yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
participants (2)
-
Desika Narayanan -
Matthew Turk