+1, except it seems like the easiest thing to do is to just make sure that Tipsy's _is_valid always returns False for now.On Apr 11, 2014, at 12:41 PM, Nathan Goldbaum <nathan12343@gmail.com> wrote:Hi all,While Ben works on his fix, would anyone object to temporarily reverting the merged pull request that triggered this behavior?I worry about FLASH users who do not read yt-dev. I guess it *is* the bleeding edge, experimental version so bugs should be expected but still, reverting seems like an easy temporary fix that takes some pressure off Ben to quickly develop a true fix to the underlying issue.Nathan_______________________________________________
On Thursday, April 10, 2014, B.W. Keller <kellerbw@mcmaster.ca> wrote:Good idea Mike! I'll do that too.On Thu, Apr 10, 2014 at 7:39 PM, Mike Warren <mswarren@gmail.com> wrote:
You could detect that it is not a tipsy file quickly, by using the
constraint in the header that nbodies=nsph+ndark+nstar and ndim is
presumably 1,2 or 3.
struct tipsy_dump {
double time;
int nbodies;
int ndim;
int nsph;
int ndark;
int nstar;
> Oh my. Sorry that I have introduced this, unfortunately there is no way to
> detect tipsy files other than actually reading the entire file from disk.
> Perhaps the way to fix this would be to drop the priority of tipsy datasets
> to the bottom, so that a valid FLASH dataset will be detected prior to the
> Tipsy check?
>
>
> On Thu, Apr 10, 2014 at 7:15 PM, Nathan Goldbaum <nathan12343@gmail.com>
> wrote:
>>
>> Hi all,
>>
>> We just had a bug report from Aaron Smith at UT Austin. The symptom is
>> that the "load" comman was taking 30 seconds to complete on his FLASH
>> dataset, which should never happen for FLASH.
>>
>> After asking him to profile the code, he produced the following profile:
>>
>> http://ngoldbaum.net/yt-load/
>>
>> It seems that the recent changes to the Tipsy frontend which allow it to
>> autodetect binary outputs have made it so in some cases non-tipsy data is
>> loaded off disk.
>>
>> I'm not sure about the best way to handle this, which is why I'm writing
>> to the list rather than issuing a PR.
>>
>> -Nathan
>>
>
>
> _______________________________________________
> yt-dev mailing list
> yt-dev@lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>
_______________________________________________
yt-dev mailing list
yt-dev@lists.spacepope.org
http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
yt-dev mailing list
yt-dev@lists.spacepope.org
http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org