July 2015 - firedrake - imperial.ac.uk

Re: [firedrake] Enforcing slip boundary condition strongly
by David Ham 10 Jul '15

10 Jul '15

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(a)imperial.ac.uk> wrote: > > > On 10 Jul 2015, at 11:37, David Ham <David.Ham(a)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 >

2 1

Archer environment
by David Ham 10 Jul '15

10 Jul '15

I notice that https://bitbucket.org/mapdes/archer-environment is empty. Is this intended or has something gone wrong? David

3 2

Re: [firedrake] Enforcing slip boundary condition strongly
by David Ham 10 Jul '15

10 Jul '15

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. On Fri, 10 Jul 2015 at 11:11 Mitchell, Lawrence < lawrence.mitchell(a)imperial.ac.uk> wrote: > > > On 10 Jul 2015, at 10:25, David Ham <David.Ham(a)imperial.ac.uk> wrote: > > > > Hi Colin, > > > > That does not appear to be what Justin is asking for. He is asking how > to set a Dirichlet condition on one component of a VectorFunctionSpace. I'm > not sure we can do that right now, but I think this should be fixable. I > want to check what the Dolfin syntax for this is (so we maintain > compatibility) and then try to fix it. (Of course someone might want to > pleasantly surprise me and tell me we can do this already!) > > We can't do it at the moment, the rest of this email explains why and > sketches a possible solution. > > OK, so there are two aspects to this, which make things somewhat tricky. > > Our data model for indexing vector fields is that we store the Map to the > node and stack the dofs on top. > > To apply such slip BCs, where we only set one of the two dofs, we need to > do the following: > > - Apply the BC value to the appropriate part of the vector. I think this > is reasonably straightforward and appear to have something that works. > > - Fix up the operator appropriately. This latter option is trickier. The > way we currently do this is to drop boundary conditions on the floor when > assembling the operator. This is done by flagging the appropriate > rows/columns to be dropped by putting a negative value in the Map at the > appropriate place and letting PETSc do the rest. > > For vector-valued fields we do block insertion, i.e. we insert a 2x2 block > at each location in the matrix indexed by the base map. So the current > setup can only drop complete blocks, rather than part of one (as required > in this case). > > The question is, then, how to communicate the relevant bit of information > into the code that inserts. > > How about this: > > When we splat the values in the Map we convert: > > val => -(val + 1) > > If we're apply the BC on part of the map we decorate it with the index > offset. > > We then build a local (unrolled map) and fix up the entries. The negative > offset encoding allows us to recover the correct value. > > So assembly turns from: > > A = build_element_tensor(...); > MatSetValuesBlockedLocal(block_rows, block_cols, A); > > Into: > > A = build_element_tensor(...); > { > PetscInt rows[arity*dim]; > PetscInt cols[arity*dim]; > // Assume we're setting the bc on the second component. > for ( i = 0; i < arity; i++ ) { > if (row_map[i] < 0) { > rows[i*dim + 0] = dim*(-(row_map[i] + 1)); > rows[i*dim + 1] = -1; > } else { > rows[i*dim + 0] = dim*row_map[i]; > rows[i*dim + 1] = dim*row_map[i] + 1; > } > } > // Same for cols > MatSetValuesLocal(rows, cols, A); > } > > All the other options I came up with seem more complicated. > > Lawrence >

2 1

Re: [firedrake] Archer environment
by David Ham 09 Jul '15

09 Jul '15

Not sure. I just got access today so I can have a go at it once you push. On Thu, 9 Jul 2015 at 21:21 Rathgeber, Florian < florian.rathgeber(a)imperial.ac.uk> wrote: > On 09/07/15 12:24, David Ham wrote: > > I notice that https://bitbucket.org/mapdes/archer-environment is empty. > > Is this intended or has something gone wrong? > > No, I just haven't pushed yet. I'm in the process of cleaning up the > scripts, modules etc. we have in the fdrake packaging account. > > Has anyone recently run Firedrake on ARCHER? I know Michael has and > assume Eike is still running on ARCHER from time to time? > > Florian > > > David > >

1 0

Fwd: [HPC-SIG] Call for Papers: International Workshop on Sustainable Software Systems Engineering 2015
by Gorman, Gerard J 09 Jul '15

09 Jul '15

FYI Obviously a story here for automated computing etc. Begin forwarded message: From: Albert Solernou <a.solernou(a)LEEDS.AC.UK<mailto:a.solernou@LEEDS.AC.UK>> Subject: [HPC-SIG] Call for Papers: International Workshop on Sustainable Software Systems Engineering 2015 Date: 9 July 2015 11:28:58 BST To: <HPC-SIG(a)JISCMAIL.AC.UK<mailto:HPC-SIG@JISCMAIL.AC.UK>> Reply-To: HPC Special Interest Group discussion list <HPC-SIG(a)JISCMAIL.AC.UK<mailto:HPC-SIG@JISCMAIL.AC.UK>> Dear All, On behalf of the program committee I would like to invite you the International Workshop on Sustainable Software Systems Engineering 2015 (#SSSE15), to be held on Monday, October 26, 2015, in Liverpool, UK. The workshop focuses on technical sustainably and includes a broad range of topics across the spectrum of software engineering including software architectures, design patterns, process models, refactoring, technical debt etc. It aims to elicit position papers, which identify issues, challenges, opportunities and best practices in addressing software sustainment. If you want to know more, please visit the web site at: http://sustainabilitydesign.org/ssse15/. Best regards, Dr Albert Solernou -- --------------------------------- Dr Albert Solernou EPSRC Research Fellow, University of Leeds Tel: +44 (0)1133 431451

1 0