Fix convergence problems for flux_nonconservative_ersing_etal_local_jump

[patrickersing]

The current implementation of flux_nonconservative_ersing_etal_local_jump does not reach the expected convergence order on curvilinear meshes, when used with VolumeIntegralSubcellLimiting. This is because by passing the averaged normal direction we add a symmetric term to the jump part, which is inconsistent with the flux-differencing formula.

Luckily, this can be fixed by instead passing only the local normal direction to the local part of the flux. Below are convergence results for the newly added elixir_shallowwater_multilayer_convergence_sc_subcell_curved.jl for the local & averaged normal direction.

I have also verified entropy conservation for the implementation with the local normal direction for elixir_shallowwater_multilayer_ec_subcell_sc.jl.

Averaged normal direction (Old implementation)

polydeg=3:

polydeg=4:

Local normal direction (new implementation)

polydeg=3: (Convergence drop probably from EC fluxes)

polydeg=4:

---

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 99.28%. Comparing base (0dfa47b) to head (a14615b).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #131   +/-   ##
=======================================
  Coverage   99.28%   99.28%           
=======================================
  Files          94       96    +2     
  Lines        5116     5146   +30     
=======================================
+ Hits         5079     5109   +30     
  Misses         37       37           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[patrickersing]

@amrueda To prevent this problem in the future, should we just remove the option to pass the averaged normal direction to the NonConservativeJump part in calcflux_fhat!?

[amrueda]

@amrueda To prevent this problem in the future, should we just remove the option to pass the averaged normal direction to the NonConservativeJump part in calcflux_fhat!?

That's a good point. In general, I don't think that we'll ever want to pass the averaged normal direction to the NonConservativeJump part. However, we might want to pass Ja_ll and Ja_rr in the future(?) 🤔
I.e., we either pass no normal direction or we pass the two.

I suggest we just remove the normal direction argument in that routine for the time being. If we ever realize we need the two directions in the future, we can create a new PR.

[amrueda]

Thanks, @patrickersing!
This looks very good already. Besides not passing the averaged direction to the jump routine, I have the following suggestion:

[amrueda]

LGTM!