Cleanup or drop vectorwave.hh

I think this can only be done by @joe, see also #21 (closed) and !21 (merged)

This depends on my old multistep code. I think there is also an example problem somewhere.

Since the multistep code will be removed #21 (closed), this should be removed too. Unless @marian, to you want to adapt this for your new multistep operator?

I don't need vectorwave.hh for my new multistep operator. So it can go when everybody else is of that opinion.

Right. I just remembered that it might still be useful as kind of a test for global-valued shape functions. Once I'm done with maxwelldg I'm going to look at this closer and decide what to do with it.

@marian it is clear that you don't need it, but if I only keep what I need, pdelab would look pretty empty. The point is, that it is a local operator, which only works if we use a multistep method. As the multistep methods are non-functional atm, it would have to be ported to you new implementation. We can not estimate the effort to port it, but you can do this. And also I think an alternative problem, compared to Navier-Stokes might be good in order to be surer that the new implementation is mighty enough for the different problems out there.

Hmm, I thought I had some example program that used VectorWave somewhere. But I can't find it anywhere.

Also, vectorwave.hh has a newer version in dune-pm/dune/pm/models/fetd.hh, and there exist applications for it in dune-pm/appl/fetd. At least they did in 2013, I'm not sure that I have access to the current version of dune-pm.

The problem with removing vectorwave is that then we have nothing that uses edge elements anymore, so we should probably get rid of the finiteelementmap for them. And then we might also get rid of the edge elements in dune-localfunctions. Which would simplify things because then we can get rid of the infrastructure for global-valued finite elements. Some of these would be nice to keep, but I think we have no tests that exercise them so we would accumulate bitrot.

I just learned from @christi that Andreas Buhr may be using the edge-elements. However, he does stationary problems and so he does not need the multistep scheme. I'm going to ask him what he is actually using, and maybe if he can provide us with some example code that we can turn into a unit test.

mentioned in issue #24 (closed)

mentioned in merge request !29 (closed)

I have had a closer look at the code of vectorwave.hh because @christi came up with the idea to test the local operator with my new multistep implementation.

Unfortunately it is not possible because my implementation can only cope with first order temporal problems. I have implementated the multistep methods again from scratch, the same way as the onestep methods. So similar to the onestep methods, there is a MultistepGridOperator which takes to grid operators under its hood. That's why it is a quick and dirty hack and you cannot find it anywhere here on GitLab.

We should think of rewriting the instationary grid operators to be able to accept more than two grid operators. But that is something that we should do post 2.4 or even post 3.0 because there are more pressing issues to be cleaned up in pdelab.

mentioned in issue #24 (closed)

I got answer from Andreas Buhr. His example actually uses the Electrodynamic operators (see #24 (closed)), so I'm attaching it there instead. Thus we should remove vectorwave.hh.

I'll do it some time, unless someone else is quicker than me.

Assignee removed

mentioned in merge request !75 (merged)

Status changed to closed by commit d7d7105e