I didn't think about subdomain ids when I added this, but I think it should be ok.
We always have dx(domain_I, mesh_J) <--> dC(domain_I, mesh_J) This is because: dx(domain_I, mesh_J) = the uncut (whole) and visible (not overlapped by another mesh) cells of domain I of mesh J dC(domain_I, mesh_J) = the cut (partly overlapped) and visible (some part of it sticking out) cells of domain I of mesh J So then it should be safe to define dX = dx + dC: dX(domain_I, mesh_J) = union of the uncut and cut cells of domain I of mesh J or equivalently dx(domain_I, mesh_J) = the visible part of domain I of mesh J -- Anders tis 20 okt. 2015 kl 10:51 skrev Martin Sandve Alnæs <[email protected]>: > Lifting this here instead of commenting hidden inside this commit > > > https://bitbucket.org/fenics-project/ufl/commits/b1b19fcc037837fa67d9584d891f821bafe20d1d?at=master > > where Anders writes > """ > Define measure dX = dx + dC. This includes all uncut cells and the > visible portion of all cut cells. The measure dX thus naturally > corresponds to integration over the entire computational domain. > """ > > At first I thought this looks nice, but how does it work with properties > of measures such as integration domain and subdomain id? > If these are not the same for dx and dC, dX cannot be used. > > I.e. given dX = dx + dC I would assume the following to hold: > > dX(mesh1) == dx(mesh1) + dC(mesh1) > dX(3) == dx(3) + dC(3) > dX(3, domain=mesh1) == dx(3, domain=mesh1) + dC(3, domain=mesh1) > > but I'm not sure if the dC terms here are well formed. > > Martin >
_______________________________________________ fenics mailing list [email protected] http://fenicsproject.org/mailman/listinfo/fenics
