Re: [deal.II] Automatic Differentiation of the Finite Element Jacobian

2019-02-11 Thread Wolfgang Bangerth
Doug, let me add another thought I had: While the vertex locations of the mesh are hard-coded as doubles (and you won't be able to change that), there is a class MappingEulerian that allows you to provide a displacement field. This field is parameterized by a vector of some sort, and it is

Re: [deal.II] Automatic Differentiation of the Finite Element Jacobian

2019-02-11 Thread Daniel Arndt
> > I see that in a previous thread > > ( > https://groups.google.com/forum/#!searchin/dealii/tpetra%7Csort:date/dealii/I8aLPu5anrM/gBzaaqivDAAJ), > > > > you plan on switching over to Tpetra, which will also be useful for us > since > > we might instantiate those vectors with AD types. Do

Re: [deal.II] Automatic Differentiation of the Finite Element Jacobian

2019-02-11 Thread Jean-Paul Pelteret
> The derivatives with respect to the > mesh points will be needed for optimization purposes. I’m not familiar with the algorithms used in shape optimisation, but one *possible* work-around if you need derivatives wrt. the mesh points on the finite element cell level would be to do the

Re: [deal.II] Automatic Differentiation of the Finite Element Jacobian

2019-02-10 Thread Wolfgang Bangerth
On 2/8/19 1:55 PM, Doug wrote: > > We will very likely implement this work at some point in our development in a > few months. We have quite a bit of other basics to implement first since we > have just started reading through the documentation. We plan on using the > deal.ii library as the

Re: [deal.II] Automatic Differentiation of the Finite Element Jacobian

2019-02-08 Thread Doug
Thank you both for the amazingly quick reply. We will very likely implement this work at some point in our development in a few months. We have quite a bit of other basics to implement first since we have just started reading through the documentation. We plan on using the deal.ii library as

Re: [deal.II] Automatic Differentiation of the Finite Element Jacobian

2019-02-06 Thread Wolfgang Bangerth
Doug, in addition to what J-P already wrote: > We had chosen to use deal.ii since most of it looked templated in terms of > accepting the float type. However, I noticed that the FEValuesBase returns a > 'double', instead of a generic 'value_type' for the Jacobian term. That depends on the

Re: [deal.II] Automatic Differentiation of the Finite Element Jacobian

2019-02-05 Thread Jean-Paul Pelteret
Dear Doug, > Looking at the current implementation in fe_values, mapping_q_generic, and > local integrators, I see that it looks relatively easy to template the value > type since it is already partially templated. > > Is there a reason why those functions were not templates? No, its likely

[deal.II] Automatic Differentiation of the Finite Element Jacobian

2019-02-05 Thread Doug
Hello, We had chosen to use deal.ii since most of it looked templated in terms of accepting the float type. However, I noticed that the FEValuesBase returns a 'double', instead of a generic 'value_type' for the Jacobian term. Our goal would be to differentiate through the entire residual (and