2.12.2021, 9:00 - 11:00: Due to updates GitLab may be unavailable for some minutes between 09:00 and 11:00.

Commit bc9063c5 authored by Luke's avatar Luke
Browse files

changing limiter from minmod to koren

parent 4f973e97
......@@ -24,10 +24,20 @@
#if DIMENSIONS == 3
inline double kernels::finitevolumes::musclhancock::c::minmod(double a, double b) {
  • @lbovard: Why did you change the order of a and b in the function signature?

  • in the exahype code, the cell checking goes right, left while Michael's test code does left,right. thus for consistency with his code we did the same. if you want to swap back, go ahead, but you need to swap a and b in the formulas.

Please register or sign in to reply
inline double kernels::finitevolumes::musclhancock::c::minmod(double b, double a) {
assert(std::isfinite(a));
assert(std::isfinite(b));
  • NB: This should be a Peano assertion in order to speed up the code in Release build mode.

Please register or sign in to reply
//koren limiter
if(std::abs(a) < 1.e-12) {
return 0.0;
} else {
double r=b/a;
double phi=std::max(0.0, std::min(2.0*r , std::min((1.+2.*r)/3.,2.0)));
return phi*a;
}
/*
if (a * b < 0.0) { // sign is different (alternative: std::signbit and xor)
return 0.0;
} else {
......@@ -37,6 +47,7 @@ inline double kernels::finitevolumes::musclhancock::c::minmod(double a, double b
return b;
}
}
*/
}
// TODO(Dominic): Work in progress
......
  • I am not sure if overwriting the MINMOD limiter by a Koren Limiter is a good idea for all applications.

    We should rather provide a mechanism for switching between different limiters.

  • I agree. Which is why we have it as a separate branch. In fact, we wanted to ask you what the best approach for this would be.

  • 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.

  • mentioned in issue #274 (closed)

    Toggle commit list
  • mentioned in commit 6ddca16a

    Toggle commit list
  • Since Luke now uses the master branch, I implemented these features in the toolkit in 6ddca16a in the master branch, independently from this branch (and the associated one-month-old fork from master).

Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment