On May 5, 2014 5:48 PM, "Nathan Goldbaum" <nathan12343@gmail.com> wrote:
On Mon, May 5, 2014 at 2:46 PM, Britton Smith <brittonsmith@gmail.com>
Hi all,
I've been discussing with Hilary the best way to allow ProfilePlot to
work with profile data loaded from disk. It seems it would be easy enough to make a Profile object from loaded data, but the holdup is that there are a number of calls to data_source._determine_fields for simple things like checking if a field is log or linear.
I had a look at this function, which hangs off of YTDataContainer, and
noticed that it doesn't seem to really need the data container itself. I'm
wrote: thinking that this function could be moved to instead hang off of the Dataset object without a problem. If so, then ProfilePlot could much more easily be extended to work with data from disk, since you could also supply None for the data_source.
Does anyone see a problem with doing this?
I don't but Matt might.
I didn't, but now I feel like I ought to... ;) I can't remember why I thought it needed to live on the data container. It makes more sense to be on the dataset object. There is one complicating factor, which is that in theory, there is a cached "last requested" state that lives on the dataset, which might make more sense to live on the data container. This means that if you ask for "gas","density" the next time if you ask for "density" it just gives you back gas by default. If you go down this road, could you also investigate if there are performance penalties to calling it from within the FieldInfoContainer's __missing__ or __getitem__ methods? Matt
Britton
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org