[Yt-dev] Volume rendering with current (3628:da3894bf42a5) change set

Chris Malone chris.m.malone at gmail.com
Tue Jan 4 15:20:55 PST 2011


Hi Jeff,

I don't currently have a "small" dataset - most plotfiles are several gigs -
but I'll try to come up with a simple low-res test problem, which will
generate some usable data.

Chris

On Tue, Jan 4, 2011 at 5:33 PM, j s oishi <jsoishi at gmail.com> wrote:

> Hi Chris,
>
> Thanks for the Maestro bundle. I look forward to looking it over. It
> would be very helpful for testing and future integration if you could
> provide a simple Maestro dataset that you wouldn't mind making public.
> It doesn't have to be anything fancy; as long as it's small and AMR,
> we can use it for regression testing.
>
> As for splitting based on file format, I don't think that's the right
> approach in general. HDF5 is far too general, and far too small a part
> of the larger frontend for it to occupy a central part of the object
> hierarchy. The devil is in the AMR hierarchy, and the way binary data
> is patched together to form overlapping data regions. These are
> radically different between Enzo and Flash, despite the fact that they
> both store the actual binary field variables in HDF5 format. However,
> for the case of BoxLib derived file formats, it might make sense to
> make a generic BoxLib reader, and then derive Orion, Maestro, and
> Castro from that, since BoxLib provides both the binary data file
> format and the AMR hierarchy. The reason our design wasn't made that
> way is that Orion was the first non-Enzo code to be supported and the
> original designer of the Orion frontend didn't really know much about
> BoxLib. However, if there is enough support in the Maestro/Castro
> community for yt, I'd be happy to talk to you further about this. I
> know that Visit has a generic BoxLib reader, and my understanding from
> previous conversations with other Orion users is that it worked
> alright for Orion. There have been some changes to the BoxLib file
> format over time, but I was able to incorporate at least one of those
> into yt (for what we used to call "old BoxLib" files in the Orion
> group), so I think we can handle the variates.
>
> thanks again,
>
> Jeff
>
> On Tue, Jan 4, 2011 at 2:10 PM, Chris Malone <chris.m.malone at gmail.com>
> wrote:
> > Hi Matt,
> >
> >> Do you want to push your Maestro changes so that we can
> >> take a look at them, see how they are implemented?
> >>
> >
> > Please find attached my first run-through of adding Maestro support as an
> hg
> > bundle.  There were only a few things I had to change from the Orion
> > frontend because they both use the BoxLib data format.  I did have to
> make a
> > change in the OrionStaticOutput._is_valid method to distinguish between
> the
> > two formats.
> >
> > I often wondered if it would make more sense to split the frontends based
> on
> > file format, and then let each code subclass from a particular frontend?
> > For example, have an HDF5 frontend that Flash and Enzo can subclass.  I'm
> > not sure it would make things any cleaner...
> >
> > Chris
> >
> > _______________________________________________
> > Yt-dev mailing list
> > Yt-dev at lists.spacepope.org
> > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
> >
> >
> _______________________________________________
> Yt-dev mailing list
> Yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20110104/b898c509/attachment.htm>


More information about the yt-dev mailing list