'NgException: other mir not set' for surfaceL2 space

[lrtfm]

I would like to solve problems on the surface with the upwind DG method. I encounter the following problem when I run the python code

---------------------------------------------------------------------------
NgException                               Traceback (most recent call last)
<ipython-input-3-8419321b161f> in <module>
     27 f_H += IfPos(flux, flux*H_n.Trace(), flux*H_n.Trace().Other())*phi.Trace()*dr  #ds(element_boundary=True)
     28 
---> 29 f_H.Assemble()
     30 print(f_H.vec)

NgException: other mir not set, pls report to developersin Assemble LinearForm

The python code

# import netgen.gui
from ngsolve import *
from netgen.csg import *
from netgen.meshing import MeshingStep

geo = CSGeometry()
geo.Add(Sphere(Pnt(0,0,0),1))
mesh = Mesh(geo.GenerateMesh(maxh=0.5, perfstepsend=MeshingStep.MESHSURFACE))
Draw(mesh)

V_H = SurfaceL2(mesh, order=2, dgjumps=True)
H, phi = V_H.TnT()

H_0 = CoefficientFunction(1)
H_n = GridFunction(V_H)
H_n.Set(H_0)

n = specialcf.normal(mesh.dim)
local_tang = specialcf.tangential(mesh.dim)
con = Cross(n,local_tang) #co-normal pointing outside of a surface element

u_pre = CoefficientFunction((-y, x, 0))
flux = InnerProduct(u_pre,con)

dr = ds(element_boundary=True)
f_H = LinearForm(V_H)
f_H += IfPos(flux, flux*H_n.Trace(), flux*H_n.Trace().Other())*phi.Trace()*dr  #ds(element_boundary=True)

f_H.Assemble()
print(f_H.vec)

The version I use is

NGSolve-6.2.2102-111-gf096685c8

The thread mir-not-set-error mentioned this. It seems that this problem has been solved. Is my code wrong? Or, is there still a bug?

Thanks to the developers for bringing this powerful tool for us.

[schruste]

As of now, we don't support dg-integrators on surfaces. The way to go here is to use a Hybrid DG formulation for doing this. HDG is our favourite approach for these cases anyway (as long as you are solving linear systems at least).

Btw.: It's better to use the ngsolve forum for questions like this.

Best, Christoph

[lrtfm]

@schruste Thanks for your quick reply and advice. I will close this.

By the way, will this dg-integrators be supported?

[schruste]

I don't think so. When solving linear systems HDG is the preferred way (for a reason), s.t. I don't see why we would want to add this in the near future. For operator applications I think there are other ways (TraceOperator of FESpaces) to do it. There is a slim chance that we may add this if/when refactoring the assembly procedure. But I wouldn't count on that.

[lrtfm]

@schruste Thanks.