Re: [Yt-dev] EnzoFOF merger tree
Matt,
We have several ways of representing hierarchical data in yt, most of which follow this basic concept:
Object [with some supplemental data] Children [list of Objects]
I was not aware of this. Interesting.
I don't think we want to standardize on our data objects being the data objects from pydot -- I don't think we want "Clump" for instance or "Halo" to inherit from pydot.
I was certainly not suggesting that. What I was suggesting is once the clump finder or merger tree has established a relationship, it can then add this relationship to the hierarchical data object, whatever that may be.
I just thought we could figure out a way to write out dotfiles without using a big package... My original idea was to create a function something like:
def write_hierarchical_dotfile(base_nodes, child_node_name, supplemental_data_function_name, parent = None, f = ""): if isinstance(f, types.StringTypes): f = open(f, "w") for n in base_nodes: sdata = getattr(n, supplemental_data_function_name)() new_node = write_node(n, sdata): if parent is not None: connect_node(parent, new_node) write_hierarchical_dotfile(getattr(n, child_node_name), supplemental_data_function_name, new_node, f)
So we would still be writing dotfiles, but we could keep the nomenclature children, etc etc. Obviously this particular function would not work for multiple parents, but as an example it's closer to what I was thinking. My recollection is that the dot file format is very straightforward and simple, and we could use something like this. Does this make sense? Am I missing a big benefit that pydot provides?
I guess my main point is that if we roll our own solution, as above, we're just going to reinvent the wheel, again. I don't see how this is any easier than using a small package like pydot (which, again, I'm not married to, but it's an example and I have been playing with it. If you don't care about loading dot files off disk into the internal format, it's only one 2500 line file) to handle the logic of outputting to graphviz format. Additionally, with graphviz installed in the $PATH, pydot can output directly to an image format by calling graphviz directly. Another point: what is going to go into write_node()? Will it have the node shape and color hard-coded, or will that be stored in sdata? Likewise for connect_node(). If yes, things will be hard-coded, then writing a dot output routine for each (merger trees, clump finder) is the way to go (which has already been done for the most part). However, if write_node() will allow sdata to contain node attributes, then we're just re-writing what pydot already does. Stephen Skory stephenskory@yahoo.com http://stephenskory.com/ 510.621.3687 (google voice)
Hi Stephen, On Fri, Jan 14, 2011 at 6:18 PM, Stephen Skory <stephenskory@yahoo.com> wrote:
Matt,
We have several ways of representing hierarchical data in yt, most of which follow this basic concept:
Object [with some supplemental data] Children [list of Objects]
I was not aware of this. Interesting.
I don't think we want to standardize on our data objects being the data objects from pydot -- I don't think we want "Clump" for instance or "Halo" to inherit from pydot.
I was certainly not suggesting that. What I was suggesting is once the clump finder or merger tree has established a relationship, it can then add this relationship to the hierarchical data object, whatever that may be.
I just thought we could figure out a way to write out dotfiles without using a big package... My original idea was to create a function something like:
def write_hierarchical_dotfile(base_nodes, child_node_name, supplemental_data_function_name, parent = None, f = ""): if isinstance(f, types.StringTypes): f = open(f, "w") for n in base_nodes: sdata = getattr(n, supplemental_data_function_name)() new_node = write_node(n, sdata): if parent is not None: connect_node(parent, new_node) write_hierarchical_dotfile(getattr(n, child_node_name), supplemental_data_function_name, new_node, f)
So we would still be writing dotfiles, but we could keep the nomenclature children, etc etc. Obviously this particular function would not work for multiple parents, but as an example it's closer to what I was thinking. My recollection is that the dot file format is very straightforward and simple, and we could use something like this. Does this make sense? Am I missing a big benefit that pydot provides?
I guess my main point is that if we roll our own solution, as above, we're just going to reinvent the wheel, again. I don't see how this is any easier than using a small package like pydot (which, again, I'm not married to, but it's an example and I have been playing with it. If you don't care about loading dot files off disk into the internal format, it's only one 2500 line file) to handle the logic of outputting to graphviz format. Additionally, with graphviz installed in the $PATH, pydot can output directly to an image format by calling graphviz directly.
Okay, sounds good. You've sold me, let's use pydot. I think we should still use something that can recurse down and call pydot appropriately, but this sounds fine to me. -Matt
Another point: what is going to go into write_node()? Will it have the node shape and color hard-coded, or will that be stored in sdata? Likewise for connect_node(). If yes, things will be hard-coded, then writing a dot output routine for each (merger trees, clump finder) is the way to go (which has already been done for the most part). However, if write_node() will allow sdata to contain node attributes, then we're just re-writing what pydot already does.
Stephen Skory stephenskory@yahoo.com http://stephenskory.com/ 510.621.3687 (google voice) _______________________________________________ Yt-dev mailing list Yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
participants (2)
-
Matthew Turk -
Stephen Skory