[firedrake] Issues with LMA of vertical derivative on extruded meshes

[Eike Mueller]

Hi Lawrence,

thanks for the explanation, so my understanding is that in general PyOP2 is not aware of the COFFEE optimisation, and the wrapper code that is generated in my PyOP2 parloop can’t handle the padding. Since I call a PyOP2 parloop directly, I don’t have any control over the wrapper code and at the moment it sounds like the only thing I can do is switch off the COFFEE optimisation (which, I suppose, has implications everwhere in the code, so I really shouldn’t do this).

Isn’t then there a problem with all PyOP2 parloops, and are you going to do something about this?

Cheers,

Eike

PS: I will only send from my bath uni account in the future, sorry about that.

> On 5 Jan 2015, at 14:46, Lawrence Mitchell <lawrence.mitchell at imperial.ac.uk> wrote:
> 
> 
> On 5 Jan 2015, at 13:02, Eike Mueller <e.mueller at bath.ac.uk <mailto:e.mueller at bath.ac.uk>> wrote:
> 
>> Hi Lawrence and Fabio,
>> 
>> It works if disable the COFFEE optimisation, as suggested by Andrew on 22/12/2014. I posted this to the list (as a reply to Andrew’s email), but then I later realised that my email reporting the issue (even though I sent it *before* Andrew alerted us about the issue with COFFEE optimisation), arrived on the list *after* my reply to Andrew’s email.
>> 
>> So at the moment I do indeed use
>> 
>> parameters["coffee"]["O2"] = False
>> 
>> and then the problem goes away.
>> 
>> Apologies for the confusion! There must be a space-time anomaly causing causality violations somewhere between here and London...
> 
> So it's not a bug, per se, in coffee, but rather, as I explained an issue with optimisations that changes the kernel signature.
> 
> Effectively what happens is something like:
> 
> originally the kernel signature is:
> 
> void foo(double A[2][1], ...);
> 
> after padding it's:
> 
> void foo(double A[2][2], ...);
> 
> in the wrapper code generator, if we're assembling into a matrix (and we know padding has been applied we do):
> 
> double buf[2][1];
> double pad_buf[2][2];
> 
> foo(pad_buf, ...);
> 
> buf[0][0] = pad_buf[0][0];
> buf[1][0] = pad_buf[1][0];
> 
> MatSetValues(..., buf, ...);
> 
> But you're assembling into a Dat and so something like this happens:
> 
> double buf[2];
> 
> foo(buf, ...);
> 
> dat[0..1] = buf[0..1]
> 
> So the buffer that's passed to the kernel is the wrong size and even if it were the right size, you're copying the wrong values out.  It would have to beL
> 
> double buf[4];
> foo(buf, ...);
> dat[0] = buf[0];
> dat[1] = buf[2];
> 
>> Thanks,
>> 
>> Eike
>> 
>> PS: Other emails I sent to the list also got delayed, sometimes by several hours, so that’s odd .
> 
> Sometimes you send from your gmail address, which is not subscribed to the list and so those mails wait until one of the moderators lets them through.
> 
> Lawrence
> _______________________________________________
> firedrake mailing list
> firedrake at imperial.ac.uk <mailto:firedrake at imperial.ac.uk>
> https://mailman.ic.ac.uk/mailman/listinfo/firedrake <https://mailman.ic.ac.uk/mailman/listinfo/firedrake>
-------------- next part --------------
HTML attachment scrubbed and removed