Re: [firedrake] hybridisation and tensor-product multigrid
Officially I'd prefer you to use FacetElement and write dot(u, n). Trace elements were a quick hack. Their FIAT implementation essentially does this, though on the reference cell, inside the tabulate() function. If anyone wants to spend half-a-day extending FIAT's trace.py to work with arbitrary H(div) elements then be my guest. On 16 March 2015 at 14:25, Cotter, Colin J <colin.cotter@imperial.ac.uk> wrote:
Hi Eike, If you take a look at the test_hybridisation_inverse branch, in tests/regression/test_hybridisation_schur, you'll see a hacked up attempt at doing this for simplices. It's a bit fiddly because you need to assemble the form multiple times, once as a mixed system and once as a single block, so I'm thinking of making a tool to automate some of this by doing automated substitutions in UFL. Lawrence and I said we might try to sketch out how to do this.
Another slight problem is that we don't have trace elements for quadrilaterals or tensor product elements at the moment. Our approach to trace spaces is also rather hacked up, we extract the facet basis functions from an H(div) basis and the tabulator returns DOFs by dotting the local basis functions by the local normal.
Andrew: presumably you didn't implement them because you anticipated some fiddliness for tensor-products?
cheers --cjc
On 16 March 2015 at 08:49, Eike Mueller <E.Mueller@bath.ac.uk> wrote:
Dear firedrakers,
I have two questions regarding the extension of a hybridised solver to a tensor-product approach:
(1) In firedrake, is there already a generic way of multiplying locally assembled matrices? I need this for the hybridised solver, so for example I want to (locally) assemble the velocity mass matrix M_u and divergence operator D and then multiply them to get, for example:
D^T M_u^{-1} D
I can create a hack by assembling them into vector-valued DG0 fields and then writing the necessary operations to multiply them and abstract that into a class (as I did for the column-assembled matrices), but I wanted to check if this is supported generically in firdrake (i.e. if there is support for working with a locally assembled matrix representation). If I can do that, then I can see how I can build all operator that are needed in the hybridised equation and for mapping between the Lagrange multipliers and pressure/velocity. For the columnwise smoother, I then need to extract bits of those locally assembled matrices and assemble them columnwise as for the DG0 case.
(2) The other ingredient we need for the Gopalakrishnan and Tan approach is a tensor-product solver in the P1 space. So can I already prolongate/restrict in the horizontal-direction only in this space? I recall that Lawrence wrote a P1 multigrid, but I presume this is for a isotropic grid which is refined in all coordinate directions. Again I can probably do it 'by hand' by just L2 projecting between the spaces, but this will not be the most efficient way. Getting the columnwise smoother should work as for the DG0 case: I need to assemble the matrix locally and then pick out the vertical couplings and build them into a columnwise matrix, which I store as a vector-valued P1 space on the horizontal host-grid.
Thanks a lot,
Eike
-- Dr Eike Hermann Mueller Lecturer in Scientific Computing
Department of Mathematical Sciences University of Bath Bath BA2 7AY, United Kingdom
+44 1225 38 6241 e.mueller@bath.ac.uk http://people.bath.ac.uk/em459/
_______________________________________________ firedrake mailing list firedrake@imperial.ac.uk https://mailman.ic.ac.uk/mailman/listinfo/firedrake
I'm happy to use FacetElement in this way, but there is one tiny wrinkle which hopefully we can figure out, namely that in TraceElement we dotted with the local normal. If we do this with FacetElement, we have to dot with the global normal, which leads to possible sign changes (you have to either choose "+" or "-"). This is fine for implementing hybridisation, but it has implications for the preconditioner, since the trace variable is used as an approximation to the DG variable solution. If we don't choose the sign correctly, then having a positive FacetElement basis coefficient could lead to a negative value of the trace variable, and then we can't map directly from FacetElement basis coefficients to CG basis coefficients in the preconditioner. To make this work, you need to consistently choose "+" or "-" for the normal. Is it the convention that positive H(div) basis coefficient leads to positive value of u.n("+")? I guess this is the real question I wanted to ask Marie yesterday, but hadn't formulated it right in my head. cheers ---cjc On 16 March 2015 at 13:46, Andrew McRae <a.mcrae12@imperial.ac.uk> wrote:
Officially I'd prefer you to use FacetElement and write dot(u, n).
Trace elements were a quick hack. Their FIAT implementation essentially does this, though on the reference cell, inside the tabulate() function.
If anyone wants to spend half-a-day extending FIAT's trace.py to work with arbitrary H(div) elements then be my guest.
On 16 March 2015 at 14:25, Cotter, Colin J <colin.cotter@imperial.ac.uk> wrote:
Hi Eike, If you take a look at the test_hybridisation_inverse branch, in tests/regression/test_hybridisation_schur, you'll see a hacked up attempt at doing this for simplices. It's a bit fiddly because you need to assemble the form multiple times, once as a mixed system and once as a single block, so I'm thinking of making a tool to automate some of this by doing automated substitutions in UFL. Lawrence and I said we might try to sketch out how to do this.
Another slight problem is that we don't have trace elements for quadrilaterals or tensor product elements at the moment. Our approach to trace spaces is also rather hacked up, we extract the facet basis functions from an H(div) basis and the tabulator returns DOFs by dotting the local basis functions by the local normal.
Andrew: presumably you didn't implement them because you anticipated some fiddliness for tensor-products?
cheers --cjc
On 16 March 2015 at 08:49, Eike Mueller <E.Mueller@bath.ac.uk> wrote:
Dear firedrakers,
I have two questions regarding the extension of a hybridised solver to a tensor-product approach:
(1) In firedrake, is there already a generic way of multiplying locally assembled matrices? I need this for the hybridised solver, so for example I want to (locally) assemble the velocity mass matrix M_u and divergence operator D and then multiply them to get, for example:
D^T M_u^{-1} D
I can create a hack by assembling them into vector-valued DG0 fields and then writing the necessary operations to multiply them and abstract that into a class (as I did for the column-assembled matrices), but I wanted to check if this is supported generically in firdrake (i.e. if there is support for working with a locally assembled matrix representation). If I can do that, then I can see how I can build all operator that are needed in the hybridised equation and for mapping between the Lagrange multipliers and pressure/velocity. For the columnwise smoother, I then need to extract bits of those locally assembled matrices and assemble them columnwise as for the DG0 case.
(2) The other ingredient we need for the Gopalakrishnan and Tan approach is a tensor-product solver in the P1 space. So can I already prolongate/restrict in the horizontal-direction only in this space? I recall that Lawrence wrote a P1 multigrid, but I presume this is for a isotropic grid which is refined in all coordinate directions. Again I can probably do it 'by hand' by just L2 projecting between the spaces, but this will not be the most efficient way. Getting the columnwise smoother should work as for the DG0 case: I need to assemble the matrix locally and then pick out the vertical couplings and build them into a columnwise matrix, which I store as a vector-valued P1 space on the horizontal host-grid.
Thanks a lot,
Eike
-- Dr Eike Hermann Mueller Lecturer in Scientific Computing
Department of Mathematical Sciences University of Bath Bath BA2 7AY, United Kingdom
+44 1225 38 6241 e.mueller@bath.ac.uk http://people.bath.ac.uk/em459/
_______________________________________________ firedrake mailing list firedrake@imperial.ac.uk https://mailman.ic.ac.uk/mailman/listinfo/firedrake
_______________________________________________ firedrake mailing list firedrake@imperial.ac.uk https://mailman.ic.ac.uk/mailman/listinfo/firedrake
I'd be happy to discuss more today. (I need a little more detail to understand the question.) -- Marie
On 16 Mar 2015, at 08:48, Colin Cotter <colin.cotter@imperial.ac.uk> wrote:
To make this work, you need to consistently choose "+" or "-" for the normal. Is it the convention that positive H(div) basis coefficient leads to positive value of u.n("+")? I guess this is the real question I wanted to ask Marie yesterday, but hadn't formulated it right in my head.
Hi Colin, I'm not sure I understand that. If we represent the trace space by a vector-valued field \vec{Lambda} (which I presume a FacetElement is used for), isn't everything consistent if we use lambda=\vec{Lambda}.\vec{n} when we reconstruct the DG and H(div) fields from the trace space and also use \vec{Lambda_{test}}.\vec{n} when we assemble any forms in the hybridised operator? Or is the problem that we can't get access to the normal \vec{n} in both cases? Thanks, Eike On 16/03/15 14:48, Colin Cotter wrote:
I'm happy to use FacetElement in this way, but there is one tiny wrinkle which hopefully we can figure out, namely that in TraceElement we dotted with the local normal. If we do this with FacetElement, we have to dot with the global normal, which leads to possible sign changes (you have to either choose "+" or "-"). This is fine for implementing hybridisation, but it has implications for the preconditioner, since the trace variable is used as an approximation to the DG variable solution. If we don't choose the sign correctly, then having a positive FacetElement basis coefficient could lead to a negative value of the trace variable, and then we can't map directly from FacetElement basis coefficients to CG basis coefficients in the preconditioner.
To make this work, you need to consistently choose "+" or "-" for the normal. Is it the convention that positive H(div) basis coefficient leads to positive value of u.n("+")? I guess this is the real question I wanted to ask Marie yesterday, but hadn't formulated it right in my head.
cheers ---cjc
On 16 March 2015 at 13:46, Andrew McRae <a.mcrae12@imperial.ac.uk <mailto:a.mcrae12@imperial.ac.uk>> wrote:
Officially I'd prefer you to use FacetElement and write dot(u, n).
Trace elements were a quick hack. Their FIAT implementation essentially does this, though on the reference cell, inside the tabulate() function.
If anyone wants to spend half-a-day extending FIAT's trace.py to work with arbitrary H(div) elements then be my guest.
On 16 March 2015 at 14:25, Cotter, Colin J <colin.cotter@imperial.ac.uk <mailto:colin.cotter@imperial.ac.uk>> wrote:
Hi Eike, If you take a look at the test_hybridisation_inverse branch, in tests/regression/test_hybridisation_schur, you'll see a hacked up attempt at doing this for simplices. It's a bit fiddly because you need to assemble the form multiple times, once as a mixed system and once as a single block, so I'm thinking of making a tool to automate some of this by doing automated substitutions in UFL. Lawrence and I said we might try to sketch out how to do this.
Another slight problem is that we don't have trace elements for quadrilaterals or tensor product elements at the moment. Our approach to trace spaces is also rather hacked up, we extract the facet basis functions from an H(div) basis and the tabulator returns DOFs by dotting the local basis functions by the local normal.
Andrew: presumably you didn't implement them because you anticipated some fiddliness for tensor-products?
cheers --cjc
On 16 March 2015 at 08:49, Eike Mueller <E.Mueller@bath.ac.uk <mailto:E.Mueller@bath.ac.uk>> wrote:
Dear firedrakers,
I have two questions regarding the extension of a hybridised solver to a tensor-product approach:
(1) In firedrake, is there already a generic way of multiplying locally assembled matrices? I need this for the hybridised solver, so for example I want to (locally) assemble the velocity mass matrix M_u and divergence operator D and then multiply them to get, for example:
D^T M_u^{-1} D
I can create a hack by assembling them into vector-valued DG0 fields and then writing the necessary operations to multiply them and abstract that into a class (as I did for the column-assembled matrices), but I wanted to check if this is supported generically in firdrake (i.e. if there is support for working with a locally assembled matrix representation). If I can do that, then I can see how I can build all operator that are needed in the hybridised equation and for mapping between the Lagrange multipliers and pressure/velocity. For the columnwise smoother, I then need to extract bits of those locally assembled matrices and assemble them columnwise as for the DG0 case.
(2) The other ingredient we need for the Gopalakrishnan and Tan approach is a tensor-product solver in the P1 space. So can I already prolongate/restrict in the horizontal-direction only in this space? I recall that Lawrence wrote a P1 multigrid, but I presume this is for a isotropic grid which is refined in all coordinate directions. Again I can probably do it 'by hand' by just L2 projecting between the spaces, but this will not be the most efficient way. Getting the columnwise smoother should work as for the DG0 case: I need to assemble the matrix locally and then pick out the vertical couplings and build them into a columnwise matrix, which I store as a vector-valued P1 space on the horizontal host-grid.
Thanks a lot,
Eike
-- Dr Eike Hermann Mueller Lecturer in Scientific Computing
Department of Mathematical Sciences University of Bath Bath BA2 7AY, United Kingdom
+44 1225 38 6241 <tel:%2B44%201225%2038%206241> e.mueller@bath.ac.uk <mailto:e.mueller@bath.ac.uk> http://people.bath.ac.uk/__em459/ <http://people.bath.ac.uk/em459/>
_________________________________________________ firedrake mailing list firedrake@imperial.ac.uk <mailto:firedrake@imperial.ac.uk> https://mailman.ic.ac.uk/__mailman/listinfo/firedrake <https://mailman.ic.ac.uk/mailman/listinfo/firedrake>
_______________________________________________ firedrake mailing list firedrake@imperial.ac.uk <mailto:firedrake@imperial.ac.uk> https://mailman.ic.ac.uk/mailman/listinfo/firedrake
_______________________________________________ firedrake mailing list firedrake@imperial.ac.uk https://mailman.ic.ac.uk/mailman/listinfo/firedrake
-- Dr Eike Hermann Mueller Lecturer in Scientific Computing Department of Mathematical Sciences University of Bath Bath BA2 7AY, United Kingdom +44 1225 38 6241 e.mueller@bath.ac.uk http://people.bath.ac.uk/em459/
participants (4)
-
Andrew McRae
-
Colin Cotter
-
Eike Mueller
-
Marie E. Rognes