[yt-users] Accessing data

[Matthew Turk]

Hi Stuart,

On Wed, Nov 6, 2013 at 9:44 AM, Stuart Mumford <stuart at mumford.me.uk> wrote:
> Yes, we definitely want you to get your arrays.  -999 means an unfilled
> cell.
>>
>> Which version of yt are you using?  Can you get the changeset hash?
>> And, maybe we can run some diagnostics to check that the data is in
>> fact correctly read in.  What's the output of ts[10].h.print_stats() ?
>
>
> I just updated my repo so I am now on 8913:11eefbd39a54 which gives the same
> results. (I really should go up to 3.0?)
>
> ts[10].h.print_stats()
>
> level # grids       # cells     # cells^3
> ----------------------------------------------
>   0     1       2097152           127
> ----------------------------------------------
>         1       2097152

Okay, so it's one big grid.  You can -- in this *particular* case --
also just do:

pf.h.grids[0]

which will be the same as a covering grid covering the whole domain,
since it's the grid that covers the whole domain!  :)

I'd say stay on 2.x for now, since you're still developing the frontend.

>
>
> t = 1.11794008e+01 = 1.11794008e+01 s = 3.54253834e-07 years
>
> Smallest Cell:
> Width: 4.920e-19 Mpc
> Width: 4.920e-19 mpc
> Width: 4.920e-16 kpc
> Width: 4.920e-13 pc
> Width: 1.015e-07 au
> Width: 2.183e-05 rsun
> Width: 7.764e-03 unitary
> Width: 9.434e+00 miles
> Width: 1.518e+01 km
> Width: 1.518e+03 density_bg
> Width: 1.518e+03 density_pert
> Width: 1.518e+06 1
> Width: 1.518e+06 cm
> Width: 1.518e+07 internal_energy_bg
> Width: 1.518e+07 internal_energy_pert
> Width: 1.518e+08 velocity_x
> Width: 1.518e+08 velocity_y
> Width: 1.518e+08 velocity_z
> Width: 1.518e+10 mag_field_x_bg
> Width: 1.518e+10 mag_field_x_pert
> Width: 1.518e+10 mag_field_y_bg
> Width: 1.518e+10 mag_field_y_pert
> Width: 1.518e+10 mag_field_z_bg
> Width: 1.518e+10 mag_field_z_pert
>
> things like SlicePlot also seem to work well. I take it that covering_grid
> is the way to go here?
>
> Also is it possible to get the current h5py file instance from a timeseries?
> I have put some bonus stuff in my files that dosen't speak yt.

Not yet, but that's on the roadmap.  Britton has done some great work
with time series, and we also want to support this type of thing as
Cactus does something similar with storing info inside the base
time-series datafile.  You can open a new one and as long as you close
it, it will get the reference counting correctly.

>
>
>>
>>
>> >
>> > On another, related, note:
>> > I have a bit of code that executes in serial at the top of a otherwise
>> > embarrassingly parallel piece of vtk code, I need the most optimal io
>> > possible for this, as it is all io limited, how well is yt suited to
>> > getting
>> > one slice out of my gdf files as fast as humanly possible?
>>
>> It depends.  We actually found for *many* types of data, where the
>> grids are below a threshold, that it's faster to read in and discard
>> slices than to read hyperslabs.  This may not be the case now that we
>> are using low-level h5py code.  But I'd actually say, just give it a
>> shot?
>
>
> I am not sure I follow, what two methods are you saying I should compare?!
>

Accessing hyperslabs versus just grabbing the yt stuff.  I'm not sure
I totally understand what you're trying to do, I suppose.

> Thanks
> Stuart
>
> _______________________________________________
> yt-users mailing list
> yt-users at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>