Hi Mike, Ah! This is a fun one, and there are two possible causes for it. (Thanks for the bug report, by the way.) * The field count on disk is not the same as what yt thinks it should expect. (I don't think there's a way to detect the number or names of fields in a RAMSES file, but if there is ....) This can be fixed by supplying the argument fields to the load() command. The default field list is ["Density", "x-velocity", "y-velocity", "z-velocity", "Pressure", "Metallicity"]. So if you have any additional, or fewer than that, fields, you can specify them and it should work. * The other possibility is that your simulation has boundary conditions that live outside the domain. This was fixed very recently: https://bitbucket.org/yt_analysis/yt-3.0/pull-request/107/adding-a-count-bou... and is typically seen when the boundary is specified. If you are running 3.0, you can update with: (the directory may be different -- it may just be yt-hg -- but you can see what it is from "yt instinfo") cd $YT_DEST/src/yt-hg-3.0/ hg pull -r tip https://bitbucket.org/yt_analysis/yt-3.0 hg up python2.7 setup.py build_ext -i -f Can you try again, and let us know? Just doing "pf.h" should show the error, and if that succeeds, it should work. Sorry for the trouble! -Matt On Fri, Oct 4, 2013 at 10:09 AM, Butler,Michael J wrote:

Hi Matt,

Thanks. The problem is (which was going to be my next email, and the reason I was trying out 2.5), I can't seem to make plots in the 3.0 branch anymore since updating it. I don't recall which version it was when I could, but now I get the error at the end of the email when I try and make a slice/projection (it happens both with the PlotCollection method as well as SlicePlot).

-Mike

In [5]: pc.add_slice("Density",2) --------------------------------------------------------------------------- AssertionError Traceback (most recent call last) /home/itp/butler/yt-x86_64/src/yt-hg/scripts/iyt in <module>() ----> 1 pc.add_slice("Density",2)

/home/itp/butler/yt-x86_64/src/yt-hg/yt/visualization/plot_collection.py in add_slice(self, field, axis, coord, center, use_colorbar, figure, axes, fig_size, periodic, obj, field_parameters) 427 if obj is None: 428 if field_parameters is None: field_parameters = {} --> 429 obj = self.pf.hierarchy.slice(axis, coord, field, 430 center=center, **field_parameters) 431 p = self._add_plot(PCSlicePlot(

/home/itp/butler/yt-x86_64/src/yt-hg/yt/data_objects/static_output.py in hierarchy(self) 223 raise RuntimeError("You should not instantiate StaticOutput.") 224 self._instantiated_hierarchy = self._hierarchy_class( --> 225 self, data_style=self.data_style) 226 return self._instantiated_hierarchy 227 h = hierarchy # alias

/home/itp/butler/yt-x86_64/src/yt-hg/yt/frontends/ramses/data_structures.py in __init__(self, pf, data_style) 301 302 self.float_type = np.float64 --> 303 super(RAMSESGeometryHandler, self).__init__(pf, data_style) 304 305 def _initialize_oct_handler(self):

/home/itp/butler/yt-x86_64/src/yt-hg/yt/geometry/geometry_handler.py in __init__(self, pf, data_style) 66 67 mylog.debug("Setting up domain geometry.") ---> 68 self._setup_geometry() 69 70 mylog.debug("Initializing data grid data IO")

/home/itp/butler/yt-x86_64/src/yt-hg/yt/geometry/oct_geometry_handler.py in _setup_geometry(self) 48 def _setup_geometry(self): 49 mylog.debug("Initializing Octree Geometry Handler.") ---> 50 self._initialize_oct_handler() 51 52 def get_smallest_dx(self):

/home/itp/butler/yt-x86_64/src/yt-hg/yt/frontends/ramses/data_structures.py in _initialize_oct_handler(self) 306 nv = len(self.fluid_field_list) 307 self.domains = [RAMSESDomainFile(self.parameter_file, i + 1, nv) --> 308 for i in range(self.parameter_file['ncpu'])] 309 total_octs = sum(dom.local_oct_count #+ dom.ngridbound.sum() 310 for dom in self.domains)

/home/itp/butler/yt-x86_64/src/yt-hg/yt/frontends/ramses/data_structures.py in __init__(self, pf, domain_id, nvar) 70 self._read_amr_header() 71 self._read_particle_header() ---> 72 self._read_amr() 73 74 _hydro_offset = None

/home/itp/butler/yt-x86_64/src/yt-hg/yt/frontends/ramses/data_structures.py in _read_amr(self) 248 assert(pos.shape[0] == ng) 249 n = self.oct_handler.add(cpu + 1, level - min_level, pos) --> 250 assert(n == ng) 251 self.oct_handler.finalize() 252

AssertionError:

On Fri, 4 Oct 2013 09:11:36 -0400, Matthew Turk wrote:

Hi Mike,

The stable branch of yt probably doesn't work with RAMSES anymore... I think we even disabled it recently.

However, the 3.0 branch (listed as "bleeding edge" on the website) full supports Ramses and is considerably faster and more memory conservative. I'd suggest you give it a shot - at this point it's quite stable and production ready. The docs are still lagging but that's next up; for Ramses it should be mostly identical in usage. If you do run into any trouble, drop a line here?

Matt

On Oct 4, 2013 9:04 AM, "Butler,Michael J" wrote:

...

Hi everyone,

I have been working with the stable branch of yt to look at RAMSES data and have run into a problem. When doing simple projections of e.g. Density with take_log=True, the projection becomes blocky (see attached image). This doesn't happen if I take out the take_log line. Here is what I am doing :

pf = load("output_00427/info_00427.txt") pf.h pf.field_info['Density'].take_log = True p=SlicePlot(pf,2,"Density")

Any ideas what is going on here?

Thanks,

Mike _______________________________________________ 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 Mike, On Fri, Oct 4, 2013 at 11:31 AM, Butler,Michael J wrote:

Hi Matt,

I did the update, and can successfully do pf.h without the error. When I do try to make a slice though, I get the new error at the end of the email. I don't think the issue is with the number of fields, but could you clarify how you mean to specify fields for the load command? Would it just be some array eg. ["Density","x-velocity"....] after the filename?

Yup, that's right. You'd do: load("output_00001/info_00001.txt", fields = [....]) This error looks a bit odd -- are you able to project, or do: dd = pf.h.all_data() dd["Density"] by any chance? I think this error may need some detailed debugging; we do test the RAMSES frontend on every push, but we have limited access to data, so identifying datasets where it fails and then recreating them on our server-side testing infrastructure is valuable. I have some meetings for the next two hours or so, but do you think you could stop by IRC in a couple hours and we could work through this in low-latency? We're on #yt on chat.freenode.org (you can use Adium for that) or at http://yt-project.org/irc.html . Alternately, ping me on GTalk and we can work through it, and I will send an email here to the list when we figure it out and resolve it. Sorry for the trouble!

Also, on another note, when I load data it says the frontend assumes the simulation is cosmological, while my data is not - do you think that will cause any problems?

Not that would show up like this; I think they would only show up when dealing with the units system, which is easily verifiable. In fact I think that error is largely vestigial, as the only difference would be when asking cosmological quantities. -Matt

Thanks again,

Mike

In [7]: pc.add_slice("Density",2)--------------------------------------------------------------------------- ValueError Traceback (most recent call last)

/home/itp/butler/yt-x86_64/src/yt-hg/scripts/iyt in <module>() ----> 1 pc.add_slice("Density",2)

/home/itp/butler/yt-x86_64/src/yt-hg/yt/visualization/plot_collection.py in add_slice(self, field, axis, coord, center, use_colorbar, figure, axes, fig_size, periodic, obj, field_parameters) 422 obj, field, use_colorbar=use_colorbar, 423 axes=axes, figure=figure, --> 424 size=fig_size, periodic=periodic)) 425 mylog.info("Added slice of %s at %s = %s with 'center' = %s", field, 426 axis_names[axis], coord, list(center))

/home/itp/butler/yt-x86_64/src/yt-hg/yt/visualization/plot_types.py in __init__(self, data, field, figure, axes, use_colorbar, size, periodic) 314 self.label_kws = {} 315 self.__setup_from_field(field) --> 316 self.__init_temp_image(use_colorbar) 317 318 def __setup_from_field(self, field):

/home/itp/butler/yt-x86_64/src/yt-hg/yt/visualization/plot_types.py in __init_temp_image(self, setup_colorbar) 351 else: 352 self.colorbar = None --> 353 self.set_width(1,'unitary') 354 355 def _get_buff(self, width=None):

/home/itp/butler/yt-x86_64/src/yt-hg/yt/visualization/plot_types.py in set_width(self, width, unit) 446 unit = self.data.pf[str(unit)] 447 self.width = width / unit --> 448 self._refresh_display_width() 449 450 def _refresh_display_width(self, width=None):

/home/itp/butler/yt-x86_64/src/yt-hg/yt/visualization/plot_types.py in _refresh_display_width(self, width) 464 self.set_xlim(max(l_edge_x,self.xmin), min(r_edge_x,self.xmax)) 465 self.set_ylim(max(l_edge_y,self.ymin), min(r_edge_y,self.ymax)) --> 466 self._redraw_image() 467 468 def autoscale(self):

/home/itp/butler/yt-x86_64/src/yt-hg/yt/visualization/plot_types.py in _redraw_image(self, *args) 381 382 def _redraw_image(self, *args): --> 383 buff = self._get_buff() 384 if self[self.axis_names["Z"]].size == 0: 385 raise YTNoDataInObjectError(self.data)

/home/itp/butler/yt-x86_64/src/yt-hg/yt/visualization/plot_types.py in _get_buff(self, width) 370 else: 371 check_period = 0 --> 372 buff = _MPL.Pixelize(self.data['px'], 373 self.data['py'], 374 self.data['pdx'],

/home/itp/butler/yt-x86_64/src/yt-hg/yt/data_objects/data_containers.py in __getitem__(self, key) 184 if f not in self.field_data and key not in self.field_data: 185 if f in self._container_fields: --> 186 self.field_data[f] = self._generate_container_field(f) 187 return self.field_data[f] 188 else:

/home/itp/butler/yt-x86_64/src/yt-hg/yt/data_objects/selection_data_containers.py in _generate_container_field(self, field) 196 self.hierarchy._identify_base_chunk(self) 197 if field == "px": --> 198 return self._current_chunk.fcoords[:,x_dict[self.axis]] 199 elif field == "py": 200 return self._current_chunk.fcoords[:,y_dict[self.axis]]

/home/itp/butler/yt-x86_64/src/yt-hg/yt/geometry/geometry_handler.py in cached_func(self) 511 return getattr(self, n) 512 if self.data_size is None: --> 513 tr = self._accumulate_values(n[1:]) 514 else: 515 tr = func(self)

/home/itp/butler/yt-x86_64/src/yt-hg/yt/geometry/geometry_handler.py in _accumulate_values(self, method) 538 f = getattr(obj, mname) 539 arrs.append(f(self.dobj)) --> 540 arrs = np.concatenate(arrs) 541 self.data_size = arrs.shape[0] 542 return arrs

ValueError: need at least one array to concatenate

On Fri, 4 Oct 2013 10:14:12 -0400, Matthew Turk wrote:

...

Hi Mike,

Ah! This is a fun one, and there are two possible causes for it. (Thanks for the bug report, by the way.)

* The field count on disk is not the same as what yt thinks it should expect. (I don't think there's a way to detect the number or names of fields in a RAMSES file, but if there is ....) This can be fixed by supplying the argument fields to the load() command. The default field list is ["Density", "x-velocity", "y-velocity", "z-velocity", "Pressure", "Metallicity"]. So if you have any additional, or fewer than that, fields, you can specify them and it should work. * The other possibility is that your simulation has boundary conditions that live outside the domain. This was fixed very recently:

https://bitbucket.org/yt_analysis/yt-3.0/pull-request/107/adding-a-count-bou... and is typically seen when the boundary is specified. If you are running 3.0, you can update with:

(the directory may be different -- it may just be yt-hg -- but you can see what it is from "yt instinfo")

cd $YT_DEST/src/yt-hg-3.0/ hg pull -r tip https://bitbucket.org/yt_analysis/yt-3.0 hg up python2.7 setup.py build_ext -i -f

Can you try again, and let us know? Just doing "pf.h" should show the error, and if that succeeds, it should work.

Sorry for the trouble!

-Matt

On Fri, Oct 4, 2013 at 10:09 AM, Butler,Michael J wrote:

...

Hi Matt,

Thanks. The problem is (which was going to be my next email, and the reason I was trying out 2.5), I can't seem to make plots in the 3.0 branch anymore since updating it. I don't recall which version it was when I could, but now I get the error at the end of the email when I try and make a slice/projection (it happens both with the PlotCollection method as well as SlicePlot).

-Mike

In [5]: pc.add_slice("Density",2)

--------------------------------------------------------------------------- AssertionError Traceback (most recent call last) /home/itp/butler/yt-x86_64/src/yt-hg/scripts/iyt in <module>() ----> 1 pc.add_slice("Density",2)

/home/itp/butler/yt-x86_64/src/yt-hg/yt/visualization/plot_collection.py in add_slice(self, field, axis, coord, center, use_colorbar, figure, axes, fig_size, periodic, obj, field_parameters) 427 if obj is None: 428 if field_parameters is None: field_parameters = {} --> 429 obj = self.pf.hierarchy.slice(axis, coord, field, 430 center=center, **field_parameters) 431 p = self._add_plot(PCSlicePlot(

/home/itp/butler/yt-x86_64/src/yt-hg/yt/data_objects/static_output.py in hierarchy(self) 223 raise RuntimeError("You should not instantiate StaticOutput.") 224 self._instantiated_hierarchy = self._hierarchy_class( --> 225 self, data_style=self.data_style) 226 return self._instantiated_hierarchy 227 h = hierarchy # alias

/home/itp/butler/yt-x86_64/src/yt-hg/yt/frontends/ramses/data_structures.py in __init__(self, pf, data_style) 301 302 self.float_type = np.float64 --> 303 super(RAMSESGeometryHandler, self).__init__(pf, data_style) 304 305 def _initialize_oct_handler(self):

/home/itp/butler/yt-x86_64/src/yt-hg/yt/geometry/geometry_handler.py in __init__(self, pf, data_style) 66 67 mylog.debug("Setting up domain geometry.") ---> 68 self._setup_geometry() 69 70 mylog.debug("Initializing data grid data IO")

/home/itp/butler/yt-x86_64/src/yt-hg/yt/geometry/oct_geometry_handler.py in _setup_geometry(self) 48 def _setup_geometry(self): 49 mylog.debug("Initializing Octree Geometry Handler.") ---> 50 self._initialize_oct_handler() 51 52 def get_smallest_dx(self):

/home/itp/butler/yt-x86_64/src/yt-hg/yt/frontends/ramses/data_structures.py in _initialize_oct_handler(self) 306 nv = len(self.fluid_field_list) 307 self.domains = [RAMSESDomainFile(self.parameter_file, i + 1, nv) --> 308 for i in range(self.parameter_file['ncpu'])] 309 total_octs = sum(dom.local_oct_count #+ dom.ngridbound.sum() 310 for dom in self.domains)

/home/itp/butler/yt-x86_64/src/yt-hg/yt/frontends/ramses/data_structures.py in __init__(self, pf, domain_id, nvar) 70 self._read_amr_header() 71 self._read_particle_header() ---> 72 self._read_amr() 73 74 _hydro_offset = None

/home/itp/butler/yt-x86_64/src/yt-hg/yt/frontends/ramses/data_structures.py in _read_amr(self) 248 assert(pos.shape[0] == ng) 249 n = self.oct_handler.add(cpu + 1, level - min_level, pos) --> 250 assert(n == ng) 251 self.oct_handler.finalize() 252

AssertionError:

On Fri, 4 Oct 2013 09:11:36 -0400, Matthew Turk wrote:

Hi Mike,

The stable branch of yt probably doesn't work with RAMSES anymore... I think we even disabled it recently.

However, the 3.0 branch (listed as "bleeding edge" on the website) full supports Ramses and is considerably faster and more memory conservative. I'd suggest you give it a shot - at this point it's quite stable and production ready. The docs are still lagging but that's next up; for Ramses it should be mostly identical in usage. If you do run into any trouble, drop a line here?

Matt

On Oct 4, 2013 9:04 AM, "Butler,Michael J" wrote:

...

Hi everyone,

I have been working with the stable branch of yt to look at RAMSES data and have run into a problem. When doing simple projections of e.g. Density with take_log=True, the projection becomes blocky (see attached image). This doesn't happen if I take out the take_log line. Here is what I am doing :

pf = load("output_00427/info_00427.txt") pf.h pf.field_info['Density'].take_log = True p=SlicePlot(pf,2,"Density")

Any ideas what is going on here?

Thanks,

Mike _______________________________________________ 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