saving derived fields
Hi all, I've started dealing with a lot of time-consuming derived fields and am wondering if there is already support for writing derived fields back to the raw data files (e.g. .cpu files). If not, any thoughts on doing so? Sam
Hi Sam, This has been on my list for a while, but I have never gotten around to it. It'll be kind of important with the future things I have planned, but possibly in a different way. For now, I think it should be straightforward to implement this. As long as you do not touch the .hierarchy file itself, you should be able to (broadly speaking) add fields at will. My suggestion is to add a method to the grid object: def write_field(self, field_name): self.hierarchy.io.write_field_to_disk(self, field_name, self[field]) This would be a method of GridPatch, not EnzoGrid. Then, add to the base IOHandler object: def write_field_to_disk(self, grid, field_name, field_value): raise NotImplementedError Then in the yt/frontends/enzo/io.py, under the Packed HDF5 (and then others can implement as necessary) add a write_field_to_disk that opens (in 'a' mode) the grid.filename, just like it normally would, and writes to disk using that. If you give this a shot and test it, let us know how it goes, and feel free to push if it works out. -Matt On Tue, Jan 11, 2011 at 12:40 PM, Sam Skillman <samskillman@gmail.com> wrote:
Hi all, I've started dealing with a lot of time-consuming derived fields and am wondering if there is already support for writing derived fields back to the raw data files (e.g. .cpu files). If not, any thoughts on doing so?
Sam _______________________________________________ Yt-dev mailing list Yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
Hi Matt, Awesome, thanks for the quick response! I'll give it a go and report back. Sam On Tue, Jan 11, 2011 at 10:50 AM, Matthew Turk <matthewturk@gmail.com>wrote:
Hi Sam,
This has been on my list for a while, but I have never gotten around to it. It'll be kind of important with the future things I have planned, but possibly in a different way.
For now, I think it should be straightforward to implement this. As long as you do not touch the .hierarchy file itself, you should be able to (broadly speaking) add fields at will. My suggestion is to add a method to the grid object:
def write_field(self, field_name): self.hierarchy.io.write_field_to_disk(self, field_name, self[field])
This would be a method of GridPatch, not EnzoGrid.
Then, add to the base IOHandler object:
def write_field_to_disk(self, grid, field_name, field_value): raise NotImplementedError
Then in the yt/frontends/enzo/io.py, under the Packed HDF5 (and then others can implement as necessary) add a write_field_to_disk that opens (in 'a' mode) the grid.filename, just like it normally would, and writes to disk using that.
If you give this a shot and test it, let us know how it goes, and feel free to push if it works out.
-Matt
Hi all, I've started dealing with a lot of time-consuming derived fields and am wondering if there is already support for writing derived fields back to
On Tue, Jan 11, 2011 at 12:40 PM, Sam Skillman <samskillman@gmail.com> wrote: the
raw data files (e.g. .cpu files). If not, any thoughts on doing so?
Sam _______________________________________________ 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
participants (2)
-
Matthew Turk -
Sam Skillman