Read values of z for z views

I have a nonlinear problem I want to solve matrix free (using appropriate Newton and solver backends from exadune) that didn't run. I tried numerical differentation and implementing jacobian_apply.

Looking through PDELab led to this (potential) bug that solves the issue for me. It looked suspicious so I tried the change but for my own sanity I didn't think further about it after going through all this engine stuff ;). Because of that I'm not sure if this is really a bug or if my problems can be found elsewhere. Should be merged with care.

It does indeed look like a copy-and-paste bug. Is it possible to create some kind of test case, so that we avoid future regressions?

Marked this merge request as a Work In Progress

More complicated test cases show that there are still some strange things happening. I marked this as WIP and will write an update as soos as I know what's going on.

When I know what's going on I can write a small test that compares jacobian_application with setting up the jacobian and multiplying to a vector.

Added 1 commit:

• 1f0094f8 - Fix another typo

I found another typo bug. Now my applications are all working. Writing a test is not that easy since:

• We don't have a lop in PDELab that implements nonlinear jacobian application.
• If I write one I can't solve a problem as test since we don't have the solver in PDELab.
• So I can only compare go.nonlinear_jacobian_apply(...) with setting up a Jacobian and multiplying a vector.
• This means I have to implement a LOP with (nonlinear) jacobian_apply_method in order to compare to a jacobian_method I also have to write. In order to test all changes I need to implement something with skeleton terms, eg a DG method for a simple nonlinear problem.
• Using the applications from code generation is also kind of a mess because it is not just done with including a localoperator but we also use some other stuff (timers, different basis evaluation) which means I need to copy even more code.

Because of all that I suggest that we skip adding a test until we have code in PDELab that can actually use the nonlinear jacobian_apply_method. Right now I can only confirm that I tested it with our code generation applications. Any opinions?

Unmarked this merge request as a Work In Progress

Compare with the result of an automatic-differentiation code?

I'd like to merge this without a test case - there is a test in dune-perftool (the code-generation toolbox), and the effort for making this work correctly would completely (we'd first have to write a nonlinear LOP that implements the nonlinear_jacobian_apply() method before thinking about a test case).

Having a test case would be nice, but that belongs into a different merge request. Apart from that, Marian and I would like to change the way this nonlinear stuff works anyway (the local operator knows whether it is linear, so that's were this information should come from).

My initial question was "is it possible" and it seems it is hardly possible, so we should merge as is.

mentioned in commit 79ffadb0

Status changed to merged

Mentioned in commit andreas.nuessing/dune-pdelab@79ffadb0