[yt-dev] field line tracing problems

j s oishi jsoishi at gmail.com
Wed Mar 19 10:39:07 PDT 2014


 Hi Sam,

Sorry, I was travelling yesterday. Yes, I can absolutely give you the data.
Email me off list, and we can set a time.

thanks,

j


On Mon, Mar 17, 2014 at 5:55 PM, Sam Skillman <samskillman at gmail.com> wrote:

> Hi Jeff,
>
> I tried to catch you on IRC but I keep failing. I can't seem to reproduce
> this with load_uniform_grid, but haven't yet tried on an AMR simulation.
>  Just to be clear, after you integrate the streamlines, you call the
> .clean_streamlines() before calling path(stream_number)?
>
> Any chance you could share the data with me to help debug?  Or can we find
> a time to hack on this together?
>
> Sorry for all the trouble.
>
> Sam
>
>
> On Thu, Mar 13, 2014 at 1:08 PM, j s oishi <jsoishi at gmail.com> wrote:
>
>> Hi Sam,
>>
>> Thanks for the tips. Unfortunately, I sat down this afternoon to
>> implement this fix, but it doesn't seem to help at all. Here's what I
>> tried, in diff format:
>>
>> http://paste.yt-project.org/show/4377/
>>
>> I also moved the launching plane 2 root grid cells away from the left
>> edge of the grid. I get exactly the same results. I wasn't quite sure from
>> reading the code how many ghost cells the code uses to construct the vertex
>> data; I assumed it only uses one. Thus, I would think moving the launch
>> point 2 cells away from the edge would alleviate the problem if it were a
>> vertex centering issue.
>>
>> Do you have any further suggestions?
>>
>> thanks,
>>
>> Jeff
>>
>>
>> On Tue, Mar 11, 2014 at 1:14 AM, Sam Skillman <samskillman at gmail.com>wrote:
>>
>>> Hi Jeff,
>>>
>>> (Offline we went back and forth a bit, I think what we came to was
>>> probably right. I just want to follow up here.)
>>>
>>> The issue seems to be that during the construction of vertex-centered
>>> data, the periodicity of the fields are assumed, and the streamlines go
>>> nuts.  The ideal fix is to get non-periodic vertex-centered data working,
>>> but that might take a bit. The quick fix/hack is to modify either the
>>> get_vertex_centered_data function in yt/data_objects/grid_patch.py or the
>>> logic in _integrate_through_brick in yt/visualization/streamlines.py.  You
>>> could cut off the integration when it gets close to dx away from the
>>> left/right domain edges.
>>>
>>> Sorry this was buried, we should probably raise some sort of warning if
>>> the simulation data is not periodic.
>>>
>>> Sam
>>>
>>>
>>> On Fri, Mar 7, 2014 at 3:19 PM, j s oishi <jsoishi at gmail.com> wrote:
>>>
>>>> HI Sam,
>>>>
>>>> Nope, that gives identical results. Any other thoughts?
>>>>
>>>> j
>>>>
>>>>
>>>> On Fri, Mar 7, 2014 at 5:15 PM, Sam Skillman <samskillman at gmail.com>wrote:
>>>>
>>>>> Hi Jeff,
>>>>>
>>>>> After integrate_trhough_volume, can you call:
>>>>> streamlines.clean_streamlines()
>>>>>
>>>>> In reading this function, I think it will fail since with it
>>>>> complaining about not having a .magnitudes, so perhaps first edit that
>>>>> function to take out the references to self.magnitudes?
>>>>>
>>>>> The reason I suggest this is that I don't see where in your script it
>>>>> goes through and cleans up the ones that left the domain.
>>>>>
>>>>> If that doesn't help, let me know and I'll dive further in to this.
>>>>>
>>>>> Sorry for the hassle,
>>>>> Sam
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Mar 7, 2014 at 1:34 PM, j s oishi <jsoishi at gmail.com> wrote:
>>>>>
>>>>>> Hi All (especially Sam),
>>>>>>
>>>>>> I'm trying to understand some behavior in the streamlines that I
>>>>>> don't completely understand. I've documented the problem in a notebook here:
>>>>>>
>>>>>> https://hub.yt-project.org/nb/2tmwor
>>>>>>
>>>>>> The notebook has a full statement of the problem. In essense, I'm not
>>>>>> sure I understand why streams that I believe should terminate instantly
>>>>>> upon launch (because they should walk directly out of the box) have
>>>>>> thousands of elements in them (instead of one). I assume there are one or
>>>>>> more misconceptions in my understanding, and I'd really welcome any
>>>>>> suggestions.
>>>>>>
>>>>>> thanks,
>>>>>>
>>>>>> Jeff
>>>>>>
>>>>>> _______________________________________________
>>>>>> yt-dev mailing list
>>>>>> yt-dev at lists.spacepope.org
>>>>>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> yt-dev mailing list
>>>>> yt-dev at lists.spacepope.org
>>>>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> yt-dev mailing list
>>>> yt-dev at lists.spacepope.org
>>>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>>>
>>>>
>>>
>>> _______________________________________________
>>> yt-dev mailing list
>>> yt-dev at lists.spacepope.org
>>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>>
>>>
>>
>> _______________________________________________
>> yt-dev mailing list
>> yt-dev at lists.spacepope.org
>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>
>>
>
> _______________________________________________
> yt-dev mailing list
> yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20140319/2b4e5670/attachment.html>


More information about the yt-dev mailing list