GitLab

This is basically low priority because we have a working solution on the minmod branch: A replacement of the minmod flux limiter in the 2nd order FV scheme with something more sophisticated.

However, users need to be able to choose which flux limiter they want to have with a FV solver. Therefore, the task of this issue is the integration into the ExaHyPE options language, i.e. implement what is discussed in the comments of bc9063c5:

Thanks for the comment, @domcha. I think the way to go is to implement the flux limiter as a choice in the FV solver section in the toolkit, and to call a solver method right in the kernels::finitevolumes::musclhancock::c::solutionUpdate in place of the former minmod function. Choices would be then: minmod, koren, user-defined, where the latter creates a function stub in the generated user FV solver. Toolkit code generation as usual.

I will implement this in a seperate feature branch and merge it then into various branches (such as master, as well as Lukes current working branch, i.e. the minmod branch).

One principal thing is that this function is scalar, while it probably should be vectorized. That is easily possible with inline functions, but not any more with user-defined ones. But I don't think there is an urgent need for user-defined anyway. Maybe we can just offer a choice. Adding another one should then be an easy task.