I agree. I think that's what I was proposing. Are you on this or shall I do something? On Fri, 10 Jul 2015 at 12:14 Mitchell, Lawrence < lawrence.mitchell@imperial.ac.uk> wrote:

...

On 10 Jul 2015, at 11:37, David Ham <David.Ham@imperial.ac.uk> wrote:

That's quite yuck, however I can see the attraction as we're kind of sort of not mucking with the PyOP2 interface.

However the generated code is specific to BCs applied to a particular component, which doesn't satisfy Justin's (very standard) use case.

I think we need to encode *which* component we're changing into the map value. EG.

val = -val -(2**(30-i))

where i is the component. This can be decoded to zero the correct entry in a general purpose way. The downside is that we limit ourselves to about half a billion nodes per core. I think that's OK.

OK, so it may be that a node may have more than one component zeroed (e.g. at a corner).

So how about this:

Reserve top 2 (3?) bits to encode the component:

x = sum(2**idx for idx in indices)

val = val + (x << 29)

Convert to negative

val = -(val + 1)

In the generated code we can then unwind that and pull out the appropriate components.

This could work. They're all pretty ugly solutions, tbf.

Lawrence