'NgException: other mir not set' for surfaceL2 space
lrtfm opened this issue · comments
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.
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
@schruste Thanks for your quick reply and advice. I will close this.
By the way, will this dg-integrators be supported?
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.
@schruste Thanks.