Hi Britton, It may not be documented, but I think we can actually auto-detect them; this would add on a list of lists of strings to the hierarchy, but I think that is manageable. Would this be worthwhile? -Matt On Wed, Jan 4, 2012 at 1:24 PM, Britton Smith wrote:

Hi Sam,

That fixed it, thanks!  I actually encountered this problem while working on my own derived field that used ghost zones and was using VorticitySquared as my example for how to do it.  I think in the past it was not required to list the fields with ValidateSpatial, which is why it was working as is in older versions.  I wasn't able to find documentation on how to make fields that use ghost_zones.  If it's in there and I just missed it, could someone point me toward it?  If not, I could add something to the Creating Derived Fields section.

Britton

On Wed, Jan 4, 2012 at 11:46 AM, Sam Skillman wrote:

...

Hey Britton,

It looks like VorticitySquared wasn't specifying the necessary fields (x,y,z velocity) in the definition.  I will push a change momentarily after I look around at any other ghost zone requiring fields to make sure they work.  DivV, for example, does the right thing.

Sam

On Wed, Jan 4, 2012 at 9:32 AM, Britton Smith wrote:

...

Hi everyone,

I'm having a problem using fields that use ghost zones.  The following simple script: http://paste.yt-project.org/show/2010/

gives this error: http://paste.yt-project.org/show/bOikDPScBBtDiUGvH11X/

I am working from the tip, but I get the same behavior from yt/2.3.  In yt/2.2, everything is working.  I am working now to narrow that range down a bit, but does anyone have an idea?

Britton

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

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

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

Hey Britton,

fields documentation discussing this.  I could add that if we wanted it, but it will be good to have it reviewed, since I'm not very familiar with how it works.

Sounds good. Could you write something into a fork of the docs, and then maybe Sam or Matt or I could check and accept the pull request? j

Hi everyone, I'm finally following up on this thread. I just submitted a pull request for the docs that includes some documentation of how to create fields that use ghost zones. Some of it was a little tricky to explain, so let me know if the wording can be improved. Britton On Wed, Jan 4, 2012 at 2:03 PM, Matthew Turk wrote:

Hi Britton,

On Wed, Jan 4, 2012 at 1:32 PM, Britton Smith wrote:

...

Hi Matt,

I'm not sure I understand the change that you're talking about, but it seems that they were auto-detected in the past, since the example without them there used to work. I'm in favor of returning to that if possible. Regardless, I think it would be worthwhile to add something to the derived fields documentation discussing this. I could add that if we wanted it, but it will be good to have it reviewed, since I'm not very familiar with how it works.

I think the best solution would be to have it simply auto-detect the fields necessary, rather than mandating they be specified (which may not always give the correct results.) I'll implement this tomorrow morning.

After some digging, it seems to me that this situation arose because we fixed a bug which had silently allowed this to occur, related to checking for field parameters in fields requiring ghost zones.

-Matt

...

Britton

On Wed, Jan 4, 2012 at 1:26 PM, Matthew Turk

wrote:

...

...

Hi Britton,

It may not be documented, but I think we can actually auto-detect them; this would add on a list of lists of strings to the hierarchy, but I think that is manageable. Would this be worthwhile?

-Matt

On Wed, Jan 4, 2012 at 1:24 PM, Britton Smith wrote:

...

Hi Sam,

That fixed it, thanks! I actually encountered this problem while working on my own derived field that used ghost zones and was using VorticitySquared as my example for how to do it. I think in the past it was not required

to

...

...

list the fields with ValidateSpatial, which is why it was working as is in older versions. I wasn't able to find documentation on how to make fields that use ghost_zones. If it's in there and I just missed it, could someone point me toward it? If not, I could add something to the Creating Derived Fields section.

Britton

On Wed, Jan 4, 2012 at 11:46 AM, Sam Skillman wrote:

...

Hey Britton,

It looks like VorticitySquared wasn't specifying the necessary fields (x,y,z velocity) in the definition. I will push a change momentarily after I look around at any other ghost zone requiring fields to make sure they work. DivV, for example, does the right thing.

Sam

On Wed, Jan 4, 2012 at 9:32 AM, Britton Smith <

brittonsmith@gmail.com>

...

wrote:

...

Hi everyone,

I'm having a problem using fields that use ghost zones. The

following

...

simple script: http://paste.yt-project.org/show/2010/

gives this error: http://paste.yt-project.org/show/bOikDPScBBtDiUGvH11X/

I am working from the tip, but I get the same behavior from yt/2.3. In yt/2.2, everything is working. I am working now to narrow that range down a bit, but does anyone have an idea?

Britton

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

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

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

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

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

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

Hi, I tried to make some volume renderings with the latest tip (f7e39b91cc6b), and it was crashing because there were NaNs in the data when offset_interpolate was called. I could make it crash in a small fisheye rendering (100x100) of a 128^3 AMR simulation. I've uploaded the dataset (538MB) and script to http://www.physics.gatech.edu/~jw254/scpics/RD0009.tar http://paste.yt-project.org/show/2042/ I uploaded a diff of my debugging statement to here. http://paste.yt-project.org/show/2041/ When I reverted back to the changeset (1558cb36d03b) before the ghost zone update, this problem when away. Could someone look at this or tell me where to search for the bug? Thanks! John On 17 Jan 2012, at 17:29, Matthew Turk wrote:

Hi Britton,

Looks great. Thanks.

As a sidenote, I added the functionality to auto-detect which fields are needed; supplying them in ValidateSpatial should be faster, though. Thanks!

-Matt

On Tue, Jan 17, 2012 at 5:22 PM, Britton Smith wrote:

...

Hi everyone,

I'm finally following up on this thread. I just submitted a pull request for the docs that includes some documentation of how to create fields that use ghost zones. Some of it was a little tricky to explain, so let me know if the wording can be improved.

Britton

On Wed, Jan 4, 2012 at 2:03 PM, Matthew Turk wrote:

...

Hi Britton,

On Wed, Jan 4, 2012 at 1:32 PM, Britton Smith wrote:

...

Hi Matt,

I'm not sure I understand the change that you're talking about, but it seems that they were auto-detected in the past, since the example without them there used to work. I'm in favor of returning to that if possible. Regardless, I think it would be worthwhile to add something to the derived fields documentation discussing this. I could add that if we wanted it, but it will be good to have it reviewed, since I'm not very familiar with how it works.

I think the best solution would be to have it simply auto-detect the fields necessary, rather than mandating they be specified (which may not always give the correct results.) I'll implement this tomorrow morning.

After some digging, it seems to me that this situation arose because we fixed a bug which had silently allowed this to occur, related to checking for field parameters in fields requiring ghost zones.

-Matt

...

Britton

On Wed, Jan 4, 2012 at 1:26 PM, Matthew Turk wrote:

...

Hi Britton,

It may not be documented, but I think we can actually auto-detect them; this would add on a list of lists of strings to the hierarchy, but I think that is manageable. Would this be worthwhile?

-Matt

On Wed, Jan 4, 2012 at 1:24 PM, Britton Smith wrote:

...

Hi Sam,

That fixed it, thanks! I actually encountered this problem while working on my own derived field that used ghost zones and was using VorticitySquared as my example for how to do it. I think in the past it was not required to list the fields with ValidateSpatial, which is why it was working as is in older versions. I wasn't able to find documentation on how to make fields that use ghost_zones. If it's in there and I just missed it, could someone point me toward it? If not, I could add something to the Creating Derived Fields section.

Britton

On Wed, Jan 4, 2012 at 11:46 AM, Sam Skillman wrote: > > Hey Britton, > > It looks like VorticitySquared wasn't specifying the necessary > fields > (x,y,z velocity) in the definition. I will push a change > momentarily > after > I look around at any other ghost zone requiring fields to make sure > they > work. DivV, for example, does the right thing. > > Sam > > > On Wed, Jan 4, 2012 at 9:32 AM, Britton Smith > > wrote: >> >> Hi everyone, >> >> I'm having a problem using fields that use ghost zones. The >> following >> simple script: >> http://paste.yt-project.org/show/2010/ >> >> gives this error: >> http://paste.yt-project.org/show/bOikDPScBBtDiUGvH11X/ >> >> I am working from the tip, but I get the same behavior from yt/2.3. >> In >> yt/2.2, everything is working. I am working now to narrow that >> range >> down a >> bit, but does anyone have an idea? >> >> Britton >> >> _______________________________________________ >> yt-users mailing list >> yt-users@lists.spacepope.org >> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org >> > > > _______________________________________________ > yt-users mailing list > yt-users@lists.spacepope.org > http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org >

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

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

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

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

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

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

-- John Wise Assistant Professor of Physics Center for Relativistic Astrophysics, Georgia Tech

Hi John, I just verified that it breaks on my even simpler data with the MosaicFisheyeCamera with no_ghost=False (getting the vertex centered data). However, it does not fail when doing a normal rendering. I'm out of steam for tonight, but hopefully we'll track this down right away. If you want to do stuff for now, you can do hg backout e699c92663c2https://bitbucket.org/samskillman/yt-mosaicfisheye/changeset/e699c92663c2 and stay on the latest tip without that ghost zone change. I'm sure this'll be a high priority to fix. Best, Sam On Tue, Jan 17, 2012 at 9:24 PM, John Wise wrote:

I forgot to include the debugging output from the crash.

yt : [INFO ] 2012-01-17 23:16:58,301 Rendering fisheye of 100^2 vz = nan nan -26.912 nan, dv = 0.604703, ds = 14 6 16, dp = 0.911364 0.9 0.395297 OINDEX(0,0,0) = nan, OINDEX(0,0,1) = nan vz = nan nan -26.9203 nan, dv = 0.414264, ds = 14 6 16, dp = 0.934091 -0.1 0.585736 OINDEX(0,0,0) = nan, OINDEX(0,0,1) = nan Segmentation fault

On 17 Jan 2012, at 23:21, John Wise wrote:

...

Hi,

I tried to make some volume renderings with the latest tip (f7e39b91cc6b), and it was crashing because there were NaNs in the data when offset_interpolate was called. I could make it crash in a small fisheye rendering (100x100) of a 128^3 AMR simulation. I've uploaded the dataset (538MB) and script to

http://www.physics.gatech.edu/~jw254/scpics/RD0009.tar http://paste.yt-project.org/show/2042/

I uploaded a diff of my debugging statement to here.

http://paste.yt-project.org/show/2041/

When I reverted back to the changeset (1558cb36d03b) before the ghost zone update, this problem when away. Could someone look at this or tell me where to search for the bug?

Thanks! John

On 17 Jan 2012, at 17:29, Matthew Turk wrote:

...

Hi Britton,

Looks great. Thanks.

As a sidenote, I added the functionality to auto-detect which fields are needed; supplying them in ValidateSpatial should be faster, though. Thanks!

-Matt

...

Hi everyone,

I'm finally following up on this thread. I just submitted a pull request for the docs that includes some documentation of how to create fields

On Tue, Jan 17, 2012 at 5:22 PM, Britton Smith wrote: that

...

use ghost zones. Some of it was a little tricky to explain, so let me know if the wording can be improved.

Britton

On Wed, Jan 4, 2012 at 2:03 PM, Matthew Turk wrote:

...

Hi Britton,

On Wed, Jan 4, 2012 at 1:32 PM, Britton Smith

...

...

...

...

Hi Matt,

I'm not sure I understand the change that you're talking about, but it seems that they were auto-detected in the past, since the example without

wrote: them

...

there used to work. I'm in favor of returning to that if possible. Regardless, I think it would be worthwhile to add something to the derived fields documentation discussing this. I could add that if we wanted it, but it will be good to have it reviewed, since I'm not very familiar with how it works.

I think the best solution would be to have it simply auto-detect the fields necessary, rather than mandating they be specified (which may not always give the correct results.) I'll implement this tomorrow morning.

After some digging, it seems to me that this situation arose because we fixed a bug which had silently allowed this to occur, related to checking for field parameters in fields requiring ghost zones.

-Matt

...

Britton

On Wed, Jan 4, 2012 at 1:26 PM, Matthew Turk wrote: > > Hi Britton, > > It may not be documented, but I think we can actually auto-detect > them; this would add on a list of lists of strings to the hierarchy, > but I think that is manageable. Would this be worthwhile? > > -Matt > > On Wed, Jan 4, 2012 at 1:24 PM, Britton Smith <

brittonsmith@gmail.com>

...

> wrote: >> Hi Sam, >> >> That fixed it, thanks! I actually encountered this problem while >> working on >> my own derived field that used ghost zones and was using >> VorticitySquared as >> my example for how to do it. I think in the past it was not required >> to >> list the fields with ValidateSpatial, which is why it was working as >> is >> in >> older versions. I wasn't able to find documentation on how to make >> fields >> that use ghost_zones. If it's in there and I just missed it, could >> someone >> point me toward it? If not, I could add something to the Creating >> Derived >> Fields section. >> >> Britton >> >> >> On Wed, Jan 4, 2012 at 11:46 AM, Sam Skillman < samskillman@gmail.com> >> wrote: >>> >>> Hey Britton, >>> >>> It looks like VorticitySquared wasn't specifying the necessary >>> fields >>> (x,y,z velocity) in the definition. I will push a change >>> momentarily >>> after >>> I look around at any other ghost zone requiring fields to make sure >>> they >>> work. DivV, for example, does the right thing. >>> >>> Sam >>> >>> >>> On Wed, Jan 4, 2012 at 9:32 AM, Britton Smith >>> >>> wrote: >>>> >>>> Hi everyone, >>>> >>>> I'm having a problem using fields that use ghost zones. The >>>> following >>>> simple script: >>>> http://paste.yt-project.org/show/2010/ >>>> >>>> gives this error: >>>> http://paste.yt-project.org/show/bOikDPScBBtDiUGvH11X/ >>>> >>>> I am working from the tip, but I get the same behavior from yt/2.3. >>>> In >>>> yt/2.2, everything is working. I am working now to narrow that >>>> range >>>> down a >>>> bit, but does anyone have an idea? >>>> >>>> Britton

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

Hi Matt, Thanks very much for the quick fix! I've tested on one of my datasets, and it works now in serial and parallel. John On 01/18/2012 11:29 AM, Matthew Turk wrote:

Hi John,

I isolated the problem to when you have> 1 level jump in refinement at an Enzo root grid tile boundary. I believe the fix I just pushed (33df4ef9f06c) should fix this case without resulting in a performance degradation for other situations (i.e., FLASH simulations or nested hierarchy simulations.)

Thanks for bringing this up ...

-Matt

On Wed, Jan 18, 2012 at 12:02 AM, Sam Skillman wrote:

...

Hi John,

I just verified that it breaks on my even simpler data with the MosaicFisheyeCamera with no_ghost=False (getting the vertex centered data). However, it does not fail when doing a normal rendering. I'm out of steam for tonight, but hopefully we'll track this down right away. If you want to do stuff for now, you can do hg backout e699c92663c2 and stay on the latest tip without that ghost zone change. I'm sure this'll be a high priority to fix.

Best, Sam

On Tue, Jan 17, 2012 at 9:24 PM, John Wise wrote:

...

I forgot to include the debugging output from the crash.

yt : [INFO ] 2012-01-17 23:16:58,301 Rendering fisheye of 100^2 vz = nan nan -26.912 nan, dv = 0.604703, ds = 14 6 16, dp = 0.911364 0.9 0.395297 OINDEX(0,0,0) = nan, OINDEX(0,0,1) = nan vz = nan nan -26.9203 nan, dv = 0.414264, ds = 14 6 16, dp = 0.934091 -0.1 0.585736 OINDEX(0,0,0) = nan, OINDEX(0,0,1) = nan Segmentation fault

On 17 Jan 2012, at 23:21, John Wise wrote:

...

Hi,

I tried to make some volume renderings with the latest tip (f7e39b91cc6b), and it was crashing because there were NaNs in the data when offset_interpolate was called. I could make it crash in a small fisheye rendering (100x100) of a 128^3 AMR simulation. I've uploaded the dataset (538MB) and script to

http://www.physics.gatech.edu/~jw254/scpics/RD0009.tar http://paste.yt-project.org/show/2042/

I uploaded a diff of my debugging statement to here.

http://paste.yt-project.org/show/2041/

When I reverted back to the changeset (1558cb36d03b) before the ghost zone update, this problem when away. Could someone look at this or tell me where to search for the bug?

Thanks! John

On 17 Jan 2012, at 17:29, Matthew Turk wrote:

...

Hi Britton,

Looks great. Thanks.

As a sidenote, I added the functionality to auto-detect which fields are needed; supplying them in ValidateSpatial should be faster, though. Thanks!

-Matt

On Tue, Jan 17, 2012 at 5:22 PM, Britton Smith wrote:

...

Hi everyone,

I'm finally following up on this thread. I just submitted a pull request for the docs that includes some documentation of how to create fields that use ghost zones. Some of it was a little tricky to explain, so let me know if the wording can be improved.

Britton

On Wed, Jan 4, 2012 at 2:03 PM, Matthew Turk wrote: > > Hi Britton, > > On Wed, Jan 4, 2012 at 1:32 PM, Britton Smith > > wrote: >> Hi Matt, >> >> I'm not sure I understand the change that you're talking about, but >> it >> seems >> that they were auto-detected in the past, since the example without >> them >> there used to work. I'm in favor of returning to that if possible. >> Regardless, I think it would be worthwhile to add something to the >> derived >> fields documentation discussing this. I could add that if we wanted >> it, >> but >> it will be good to have it reviewed, since I'm not very familiar >> with >> how it >> works. > > I think the best solution would be to have it simply auto-detect the > fields necessary, rather than mandating they be specified (which may > not always give the correct results.) I'll implement this tomorrow > morning. > > After some digging, it seems to me that this situation arose because > we fixed a bug which had silently allowed this to occur, related to > checking for field parameters in fields requiring ghost zones. > > -Matt > >> >> Britton >> >> >> On Wed, Jan 4, 2012 at 1:26 PM, Matthew Turk >> wrote: >>> >>> Hi Britton, >>> >>> It may not be documented, but I think we can actually auto-detect >>> them; this would add on a list of lists of strings to the >>> hierarchy, >>> but I think that is manageable. Would this be worthwhile? >>> >>> -Matt >>> >>> On Wed, Jan 4, 2012 at 1:24 PM, Britton Smith >>> >>> wrote: >>>> Hi Sam, >>>> >>>> That fixed it, thanks! I actually encountered this problem while >>>> working on >>>> my own derived field that used ghost zones and was using >>>> VorticitySquared as >>>> my example for how to do it. I think in the past it was not >>>> required >>>> to >>>> list the fields with ValidateSpatial, which is why it was working >>>> as >>>> is >>>> in >>>> older versions. I wasn't able to find documentation on how to >>>> make >>>> fields >>>> that use ghost_zones. If it's in there and I just missed it, >>>> could >>>> someone >>>> point me toward it? If not, I could add something to the Creating >>>> Derived >>>> Fields section. >>>> >>>> Britton >>>> >>>> >>>> On Wed, Jan 4, 2012 at 11:46 AM, Sam Skillman >>>> >>>> wrote: >>>>> >>>>> Hey Britton, >>>>> >>>>> It looks like VorticitySquared wasn't specifying the necessary >>>>> fields >>>>> (x,y,z velocity) in the definition. I will push a change >>>>> momentarily >>>>> after >>>>> I look around at any other ghost zone requiring fields to make >>>>> sure >>>>> they >>>>> work. DivV, for example, does the right thing. >>>>> >>>>> Sam >>>>> >>>>> >>>>> On Wed, Jan 4, 2012 at 9:32 AM, Britton Smith >>>>> >>>>> wrote: >>>>>> >>>>>> Hi everyone, >>>>>> >>>>>> I'm having a problem using fields that use ghost zones. The >>>>>> following >>>>>> simple script: >>>>>> http://paste.yt-project.org/show/2010/ >>>>>> >>>>>> gives this error: >>>>>> http://paste.yt-project.org/show/bOikDPScBBtDiUGvH11X/ >>>>>> >>>>>> I am working from the tip, but I get the same behavior from >>>>>> yt/2.3. >>>>>> In >>>>>> yt/2.2, everything is working. I am working now to narrow that >>>>>> range >>>>>> down a >>>>>> bit, but does anyone have an idea? >>>>>> >>>>>> Britton

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

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

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

-- John Wise Assistant Professor of Physics Center for Relativistic Astrophysics, Georgia Tech

Hi John, I don't know if there's a better way, but I usually do this by overriding the default in my script before making my plot, like so: pf.field_info["density"].take_log=False pc = PlotCollection(pf) p = pc.add_ray([pf.domain_left_edge[0],0,0], [pf.domain_right_edge[0],0,0], "density") etc... -Andrew Myers On Tue, Jan 17, 2012 at 3:58 PM, John ZuHone

wrote:

Hi all,

A rather simple question that I should probably already know the answer to, but here goes:

Many fields are logged by default, which is as it should be. However, sometimes the range of the variable is not very large and a log plot just doesn't make a lot of sense.

In a slice or a projection plot in a PlotCollection, how does one suppress (or, in the opposite case, enable) the logging of the plotted variable before saving or displaying the plot?

I'm hoping there's a semi-easy way to do this without setting take_log in the field definition, but I've not come across it yet.

Best,

John _______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org

Hi Matt, Oddly, your suggestion was what I tried first and it did not work. I will try Andrew's when I get home. John Sent from John ZuHone's iPhone On Jan 17, 2012, at 9:46 PM, Matthew Turk wrote:

Andrew,

That's what I do too, to tell the truth, as it also touches the default binning method inside profile/phase methods. There's also:

p.set_log_field(False)

in your script.

-Matt

On Tue, Jan 17, 2012 at 9:16 PM, Andrew Myers wrote:

...

Hi John,

I don't know if there's a better way, but I usually do this by overriding the default in my script before making my plot, like so:

pf.field_info["density"].take_log=False pc = PlotCollection(pf) p = pc.add_ray([pf.domain_left_edge[0],0,0], [pf.domain_right_edge[0],0,0], "density") etc...

-Andrew Myers

On Tue, Jan 17, 2012 at 3:58 PM, John ZuHone wrote:

...

Hi all,

A rather simple question that I should probably already know the answer to, but here goes:

Many fields are logged by default, which is as it should be. However, sometimes the range of the variable is not very large and a log plot just doesn't make a lot of sense.

In a slice or a projection plot in a PlotCollection, how does one suppress (or, in the opposite case, enable) the logging of the plotted variable before saving or displaying the plot?

I'm hoping there's a semi-easy way to do this without setting take_log in the field definition, but I've not come across it yet.

Best,

John _______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org

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

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

Sorry for replying to an old thread, but I want to note that you need to instantiate the hierarchy before messing with field_info Something like: pf = load(Filename) pf.h pf.field_info["Density"].take_log=False pc = PlotCollection(pf) pc.add_slice('Density',0) etc... should work. Nathan Goldbaum Graduate Student Astronomy & Astrophysics, UCSC goldbaum@ucolick.org http://www.ucolick.org/~goldbaum On Jan 17, 2012, at 6:16 PM, Andrew Myers wrote:

Hi John,

I don't know if there's a better way, but I usually do this by overriding the default in my script before making my plot, like so:

pf.field_info["density"].take_log=False pc = PlotCollection(pf) p = pc.add_ray([pf.domain_left_edge[0],0,0], [pf.domain_right_edge[0],0,0], "density") etc...

-Andrew Myers

On Tue, Jan 17, 2012 at 3:58 PM, John ZuHone wrote: Hi all,

A rather simple question that I should probably already know the answer to, but here goes:

Many fields are logged by default, which is as it should be. However, sometimes the range of the variable is not very large and a log plot just doesn't make a lot of sense.

In a slice or a projection plot in a PlotCollection, how does one suppress (or, in the opposite case, enable) the logging of the plotted variable before saving or displaying the plot?

I'm hoping there's a semi-easy way to do this without setting take_log in the field definition, but I've not come across it yet.

Best,

John _______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org

!DSPAM:10175,4f162ba2220417002742! _______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org

!DSPAM:10175,4f162ba2220417002742!