problem with fields that use ghost zones
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
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
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 <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
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 <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
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. Britton On Wed, Jan 4, 2012 at 1:26 PM, Matthew Turk <matthewturk@gmail.com> 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 <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
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 Britton, On Wed, Jan 4, 2012 at 1:32 PM, Britton Smith <brittonsmith@gmail.com> 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 <matthewturk@gmail.com> 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 <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
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 <matthewturk@gmail.com> wrote:
Hi Britton,
On Wed, Jan 4, 2012 at 1:32 PM, Britton Smith <brittonsmith@gmail.com> 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 <matthewturk@gmail.com>
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 <
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 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 <brittonsmith@gmail.com> 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 <matthewturk@gmail.com> wrote:
Hi Britton,
On Wed, Jan 4, 2012 at 1:32 PM, Britton Smith <brittonsmith@gmail.com> 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 <matthewturk@gmail.com> 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 <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
_______________________________________________ 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 <brittonsmith@gmail.com> 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 <matthewturk@gmail.com> wrote:
Hi Britton,
On Wed, Jan 4, 2012 at 1:32 PM, Britton Smith <brittonsmith@gmail.com> 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 <matthewturk@gmail.com> 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 > <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
_______________________________________________ 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
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 <brittonsmith@gmail.com> 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 <matthewturk@gmail.com> wrote:
Hi Britton,
On Wed, Jan 4, 2012 at 1:32 PM, Britton Smith <brittonsmith@gmail.com> 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 <matthewturk@gmail.com> 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 >> <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
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<https://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 <jwise@physics.gatech.edu> 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 <brittonsmith@gmail.com> 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 <matthewturk@gmail.com> wrote:
Hi Britton,
On Wed, Jan 4, 2012 at 1:32 PM, Britton Smith <brittonsmith@gmail.com
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 <matthewturk@gmail.com> 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 >>> <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
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 <samskillman@gmail.com> 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 <jwise@physics.gatech.edu> 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 <brittonsmith@gmail.com> 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 <matthewturk@gmail.com> wrote:
Hi Britton,
On Wed, Jan 4, 2012 at 1:32 PM, Britton Smith <brittonsmith@gmail.com> 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 <matthewturk@gmail.com> > 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 >>>> <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
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<samskillman@gmail.com> 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<jwise@physics.gatech.edu> 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<brittonsmith@gmail.com> 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<matthewturk@gmail.com> wrote: > > Hi Britton, > > On Wed, Jan 4, 2012 at 1:32 PM, Britton Smith > <brittonsmith@gmail.com> > 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<matthewturk@gmail.com> >> 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 >>>>> <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
-- John Wise Assistant Professor of Physics Center for Relativistic Astrophysics, Georgia Tech
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
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 <jzuhone@milkyway.gsfc.nasa.gov
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
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 <atmyers@berkeley.edu> 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 <jzuhone@milkyway.gsfc.nasa.gov> 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
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 <matthewturk@gmail.com> 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 <atmyers@berkeley.edu> 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 <jzuhone@milkyway.gsfc.nasa.gov> 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
Hi John, You may have to ensure it redraws, which can be done by setting the width of the plot again. This is a problem with the current plotting engine... -Matt On Tue, Jan 17, 2012 at 9:54 PM, John ZuHone <jzuhone@milkyway.gsfc.nasa.gov> wrote:
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 <matthewturk@gmail.com> 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 <atmyers@berkeley.edu> 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 <jzuhone@milkyway.gsfc.nasa.gov> 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
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 <jzuhone@milkyway.gsfc.nasa.gov> 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!
participants (8)
-
Andrew Myers -
Britton Smith -
j s oishi -
John Wise -
John ZuHone -
Matthew Turk -
Nathan Goldbaum -
Sam Skillman