Dear Jean-Paul,
On Wednesday, July 10, 2024 at 10:42:57 PM UTC+2 Jean-Paul Pelteret wrote:
Hi Nik,
> My question is: for boundary_worker. What am I missing that the
calculated residual contributions
don’t show up in the global RHS of the system?
I think that I might have an idea as to what's g
Hi Nik,
> My question is: for boundary_worker. What am I missing that the
calculated residual contributions
don’t show up in the global RHS of the system?
I think that I might have an idea as to what's going on here. I feel that
the problem likely lies with what these lines
Vector &cell_rhs = co
On 7/8/24 08:51, Nik Markus Leuenberger wrote:
I'm opening a new thread because the question is no longer whether or how to
use deal.ii for DG/finite volume implementations, but what I hope is a more
specific question regarding a combination of step-74 and step-72.
I want to use automatic di
Dear all,
I'm opening a new thread because the question is no longer whether or how
to use deal.ii for DG/finite volume implementations, but what I hope is a
more specific question regarding a combination of step-74 and step-72.
I want to use automatic differentiation to obtain the Jacobian for
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 ite
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 use
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 differentiable
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 in
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 energ
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 reinit
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 pos
> > 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 y
> 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 followin
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 wor
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 th
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 con
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 th
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
18 matches
Mail list logo
