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