New issue 879: yt-3.0 docs website
https://bitbucket.org/yt_analysis/yt/issue/879/yt-30-docs-website
Kenza Arraki:
When I visit [3.0 docs](http://yt-project.org/docs/3.0/) with too small a browser window the top options bar collapses into a smaller drop down website. If I click on this button, the menu appears and quickly disappears again before I am able to see or select an option.
I have found this using Chrome and Firefox on OSX and Firefox on Ubuntu.
Hi all,
I've added a card for the next steps for Rockstar here:
https://trello.com/c/lqmt2hEz/40-use-yt-fof-rockstar-groups
This essentially reduces yt's interaction with Rockstar to just
calling "groupies" which does not require any communication on
Rockstar's part. The process is now to use yt to identify FOF nodes
and then filter them with Rockstar. (In my head, for some reason, I
keep thinking of this as "rocketeer.") In that card is a pastebin
that includes a working script for doing this with the current state
of the yt repo, although I think there's an off-by-one error, and the
units might be a bit wrong.
Anyway, one nice thing about this is that we can feed in different or
additional "filters" instead of Rockstar into this -- for instance,
Pfister's isoden method. It also means we can control the domain
decomp a bit more in-depth.
-Matt
Hi all,
Some issues seem to have cropped up in the disk data container in yt-3.0.
I made a disk object in a periodic simulation in the following way:
http://paste.yt-project.org/show/5021/
I then made a project of the "cylindrical_z" field, which yielded the
following:
http://i.imgur.com/0XSv5Zs.png
For reference, the domain is ~45 Mpc in length on a side, so the sphere
should be just the object at the bottom, extending a little less than
halfway up. I don't know what that top part is about. My guess is that
it's an issue with periodicity.
Secondly, I made a similar projection of the "cylindrical_r" field, which
gave this:
http://i.imgur.com/h8SEJp8.png
As you can see, it is not symmetric as one would expect. For reference,
this is what I get from yt-2.x:
http://i.imgur.com/O1xT9MI.png
This is what I would expect.
Does anyone have any insight on this?
Britton
Dear All,
My yt version is
---
Version = 2.6.1
Changeset = c7bae05dd4ef
---
If I update it to 3.0 with the command: yt update --all , will my old
analysis scripts(written for 2.6 ) works?
Thank you.
--
Reju Sam John
Hi all,
I've been asked by someone who is using yt to analyze ARTIO data (yes! they exist!). They're interested in the distribution of star particle creation times (BIRTH_TIME in the internal code nomenclature). There is code to do a conversion to age that seems to have been borrowed from the ART frontend, but it's incomplete and incorrect for z > 0, so I'm porting over the c code that we use internally in ART(IO). That's all fine and good, but there's still a residual issue with code_units that I don't quite understand and hoping someone can quickly point me in the right direction.
ARTIO defines an attribute time_unit, which is stored in the ARTIO fileset and is the correct code_time -> seconds unit conversion **at the redshift of the snapshot**. The mapping from code time to physical time is non-linear, however, so a code unit defined at a different redshift cannot be simply converted to physical time in cgs using this number (which looks like what happens now).
Is there an easy way to override code_unit -> cgs (and other) unit mappings when it's a non-linear function? I can obviously create pre-converted versions of these fields (creation_time and particle_age both defined in seconds), but that doesn't prevent someone from loading ("STAR","BIRTH_TIME") and asking yt to convert it from code units to cgs, and getting the wrong answer:
i.e.
yt.load("artio dataset").all_data()[("STAR","BIRTH_TIME")].in_cgs()
gives nonsensical values.
Douglas Rudd
Scientific Computing Consultant
Research Computing Center
drudd(a)uchicago.edu
New issue 878: PlotWindow should fail more gracefully when plotting particle fields
https://bitbucket.org/yt_analysis/yt/issue/878/plotwindow-should-fail-mor...
Nathan Goldbaum:
Right now plotting a particle field leads to a crash in the frontend's I/O subsystem when it tries to treat the particle field as if it were a mesh field.
We should check whether we're actually plotting a mesh field and then crash gracefully with a nice error message if we detect a particle field.
Responsible: ngoldbaum
Oops, I meant to push those changes to my fork. Sorry about that! They
are pretty benign changes at least.
Britton
---------- Forwarded message ----------
From: <commits-noreply(a)bitbucket.org>
Date: Wed, Aug 6, 2014 at 11:14 PM
Subject: [yt-svn] commit/yt: 2 new changesets
To: yt-svn(a)lists.spacepope.org
2 new commits in yt:
https://bitbucket.org/yt_analysis/yt/commits/c8fde451d9c9/
Changeset: c8fde451d9c9
Branch: yt
User: brittonsmith
Date: 2014-08-07 00:12:46
Summary: Remove obsolete delete.
Affected #: 1 file
diff -r 6b790e3507a791aeb1a0a801e8e8d7de7e1c56e8 -r
c8fde451d9c974cee2808ccf403e07dd26235d9e
yt/analysis_modules/halo_finding/rockstar/rockstar_interface.pyx
--- a/yt/analysis_modules/halo_finding/rockstar/rockstar_interface.pyx
+++ b/yt/analysis_modules/halo_finding/rockstar/rockstar_interface.pyx
@@ -233,7 +233,6 @@
fi += 1
pi += npart
num_p[0] = local_parts
- del ds._instantiated_hierarchy
del ds
cdef class RockstarInterface:
https://bitbucket.org/yt_analysis/yt/commits/b5fbf5e597b0/
Changeset: b5fbf5e597b0
Branch: yt
User: brittonsmith
Date: 2014-08-07 00:13:56
Summary: Fixing bug in halo profiling callback.
Affected #: 1 file
diff -r c8fde451d9c974cee2808ccf403e07dd26235d9e -r
b5fbf5e597b0ca207db496e1e5d131ffc1239338
yt/analysis_modules/halo_analysis/halo_callbacks.py
--- a/yt/analysis_modules/halo_analysis/halo_callbacks.py
+++ b/yt/analysis_modules/halo_analysis/halo_callbacks.py
@@ -225,13 +225,13 @@
# accumulate, if necessary
if accumulation:
- used = my_profile.used
+ used = my_profile.used
for field in my_profile.field_data:
if weight_field is None:
my_profile.field_data[field][used] = \
np.cumsum(my_profile.field_data[field][used])
else:
- my_weight = my_profile.weight[:, 0]
+ my_weight = my_profile.weight
my_profile.field_data[field][used] = \
np.cumsum(my_profile.field_data[field][used] *
my_weight[used]) / \
np.cumsum(my_weight[used])
Repository URL: https://bitbucket.org/yt_analysis/yt/
--
This is a commit notification from bitbucket.org. You are receiving
this because you have the service enabled, addressing the recipient of
this email.
_______________________________________________
yt-svn mailing list
yt-svn(a)lists.spacepope.org
http://lists.spacepope.org/listinfo.cgi/yt-svn-spacepope.org
Hi all, especially Nathan,
What do you think about moving the functions:
get_sanitized_center
get_sanitized_width
get_window_parameters
get_oblique_window_parameters
into the coordinate handler (ds.coordinates)? This would make it
easier to implement them more carefully and clearly for the different
coordinate systems, like spherical, cylindrical, etc.
-Matt
The yt conda packages that Continuum Analytics builds for us as part of the
anaconda python distribution have just been updated for yt 3.0.
Most importantly, there is now a 64 bit Windows build along with the OSX
and Linux builds!
Right now there are only 64 bit packages, but we should have 32 bit
packages soon after fixing an issue that causes test failures on 32 bit
builds of yt.
If you use conda, you should be able to update yt with "conda update yt".
Thanks to Aaron Meurer for helping us out with this yesterday and today.
