[Yt-dev] EnzoFOF merger tree

Matthew Turk matthewturk at gmail.com
Fri Jan 14 18:24:06 PST 2011


Hi Stephen,

On Fri, Jan 14, 2011 at 6:18 PM, Stephen Skory <stephenskory at 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 at yahoo.com
> http://stephenskory.com/
> 510.621.3687 (google voice)
> _______________________________________________
> Yt-dev mailing list
> Yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>



More information about the yt-dev mailing list