My problem is nonlinear but steady-state and I formulated the residual r
associated with the pde as r = r(u(E), E).
After the last Newton-iteration, the residual is nearly 0 and the chain
rule gives
0 = dr/dU * dU/dE + dr/dE
0 = K*dU/dE + dr/dE
dU/dE = -K^-1 * dr/dE (--> evaluate after the last
It depends on what kind of problem you have, linear or nonlinear, steady-state
or transient.
For example, in case of a linear BVP you may have
A(E) U(E) = b(E)
then
A(E) U’(E) = b’(E) - A’(E) U(E)
Use AD to compute b’(E), A’(E) which involves applying AD to the assemble
process, that is
Dear all,
I want to differentiate my pde solution U with respect to some design
variables E, that is, computing the Jacobian dU/dE.
I already implemented the Jacobian analytically, however, I would like to
double check it using AD.
" (In theory an entire program could be made
Hi Simon,
Sorry that I didn't get back to you on this before now. I think that I get
the gist of what you're trying to do, but I must admit that I'm a bit
skeptical as to whether or not its going to work (the AD framework was not
really conceptualised to be used in this manner, so it will be
Hi Jean-Paul,
thanks for pointing that out.
However, I believe there has been a misunderstanding:
I am working here with a FE discretized energy on a seperate triangulation,
say, 'triangulation_energy', with the coordinates being the first and third
invariant of 'C'; The corresponding nodal
Hi Simon,
Unfortunately I don’t have the time at this moment to give you a full
explanation as to why the logic of your code is wrong, but in essence you have
the sequence of operations inverted. You need to compute your energy based on
the “sensitive” DoF values that would come from the
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
> > 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
> 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
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
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
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
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
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
14 matches
Mail list logo
