Hi Chris, Sorry for the brief reply (I'm actually on vacation while moving, stealing a bit of time at the computer.) On Thu, Dec 30, 2010 at 1:44 PM, Chris Malone wrote:

Hi Matt,

Thanks for the feedback.

...

That's a bit odd!  My guess is that something's up with the center and domain left edge info.  Can you run with --detailed or --paste-detailed, and it should give info about the center and LE variables.  Alternately, you can run with:

python2.6 -m pdb some_script.py

and print LE, LE.shape, self.back_center, self.back_center.shape.  It seems likely to me it's something like one is shaped (3,1) and the other (1,3) or (3,) or something.

After using the debugger as you suggested and looking more closely it seems that LE is still an empty list because self.bricks = None even after a call to self.partition_grids().  The latter is not working properly because self._brick_collection.source._grids is an empty ndarray.  For example, I get the following DEBUG message before the fatal error:

yt         DEBUG      2010-12-30 16:40:49,932 Preloading ['Density'] from 0 grids

I now need to track down why _grids is not being filled appropriately; all the other grid-type-lists I have found are properly filled.

My guess is actually the width argument -- you're setting it to 1.0, and the center to 0.5, 0.5, 0.5. Can you try with: W = pf['unitary'] c = 0.5*(pf.domain_right_edge + pf.domain_left_edge) which should grab all the bricks?

...

Do you want to push your Maestro changes so that we can take a look at them, see how they are implemented?

I have some clean-up to do on the code, but I will certainly push it once I have things a bit better organized.

Awesome! -Matt

Chris

...

-Matt

On Wed, Dec 29, 2010 at 4:19 PM, Chris Malone wrote:

...

Hi all,

As previously mentioned, I'm working in my spare time to add support for the Maestro code to yt.  I am able to read in the data, make slices of various variables, and save the resulting plots.  I tried, however, to follow the cookbook recipe for volume rendering and I keep getting an error while attempting to ray_cast.

Here is the script I use: http://paste.enzotools.org/show/1470/

and here is the traceback: http://paste.enzotools.org/show/Jn7X2pBPkUD0yhhLwrVv/

I'm not sure if this is an issue with the way I have implemented Maestro support or if there is a bug in the visualization.  Could someone please try my script with their own parameter file to at least verify there is no bug in ray_cast?

Thanks,

Chris

_______________________________________________ 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

_______________________________________________ Yt-dev mailing list Yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

Hi Chris, On Tue, Jan 4, 2011 at 7:21 AM, Chris Malone wrote:

Hi Matt,

...

...

After using the debugger as you suggested and looking more closely it seems that LE is still an empty list because self.bricks = None even after a call to self.partition_grids().  The latter is not working properly because self._brick_collection.source._grids is an empty ndarray.  For example, I get the following DEBUG message before the fatal error:

yt         DEBUG      2010-12-30 16:40:49,932 Preloading ['Density'] from 0 grids

I now need to track down why _grids is not being filled appropriately; all the other grid-type-lists I have found are properly filled.

My guess is actually the width argument -- you're setting it to 1.0, and the center to 0.5, 0.5, 0.5.  Can you try with:

W = pf['unitary'] c = 0.5*(pf.domain_right_edge + pf.domain_left_edge)

which should grab all the bricks?

Ok, that makes a bit more sense - I always thought the width and center values were relative coordinates.  Fixing c to be the physical center of the domain worked, but I had to modify W to be the physical width:

    W = pf.domain_right_edge - pf.domain_left_edge

to grab the bricks.  As far as I can tell with all the other frontends,

    pf['unitary'] = (1.0 / (pf.domain_right_edge - pf.domain_left_edge)).max(),

which is a a pretty small number.  With these fixes I'm at least getting a volume rendered image, but I'm not sure exactly what it is - it looks strange, but I'll play with the transfer functions and such to see if I can quantify what I mean by "strange."

Ahhh, I messed up -- it should be 1.0/pf['unitary'] It's also possible something funky is going on, so if you'd like, feel free to send some images and the TransferFunction instantiation so we can take a whack. I think it's pretty important that we have an intuitive interface to volume rendering! -Matt

Chris

_______________________________________________ Yt-dev mailing list Yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

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 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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

Hi Chris, Sorry for the delay. I have pushed your changes to the main yt repository. Thanks for your contribution. Once you get a sample dataset to me (off list!), I can start to look in more detail at your code. Having reviewed your changesets, I agree that we really need to make a unified BoxLib frontend that Orion, MAESTRO, and CASTRO all inherit from. I will see if I can also get my hands on a CASTRO dataset too. I suspect we can make this happen fairly quickly, once I can find some time to sit down and do it. thanks again, j On Tue, Jan 4, 2011 at 2:10 PM, Chris Malone 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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org