Volume rendering with current (3628:da3894bf42a5) change set
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
Hi Chris, 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. Anyway, regardless, looking over your script it may just be a mistake somewhere in yt or at the very best it's something that should work but doesn't. Do you want to push your Maestro changes so that we can take a look at them, see how they are implemented? -Matt On Wed, Dec 29, 2010 at 4:19 PM, Chris Malone <chris.m.malone@gmail.com> 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
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. 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. Chris
-Matt
Hi all,
As previously mentioned, I'm working in my spare time to add support for
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
On Wed, Dec 29, 2010 at 4:19 PM, Chris Malone <chris.m.malone@gmail.com> wrote: the 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
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 <chris.m.malone@gmail.com> 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 <chris.m.malone@gmail.com> 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 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." Chris
Hi Chris, On Tue, Jan 4, 2011 at 7:21 AM, Chris Malone <chris.m.malone@gmail.com> 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 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
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@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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
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@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
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
On Tue, Jan 4, 2011 at 2:10 PM, Chris Malone <chris.m.malone@gmail.com> wrote: 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
_______________________________________________ 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 <chris.m.malone@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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
participants (3)
-
Chris Malone -
j s oishi -
Matthew Turk