There is really no concept of "visible" in the UFL syntax. The interesting question is what a measure will map to during assembly. In the case of dx, this will map to assemble_cells, and in the case of multiple meshes, the assembly will happen over all cells in all meshes that are not overlapped by another mesh (completely or partly).
Another option would be to reserve dx for all cells of all meshes, but I'm not sure that's very useful. In that case we could introduce dU = uncut cells (what we now use dx for) and then have dX = dU + dC (all visible part of all subdomains of all domains) -- Anders tis 20 okt. 2015 kl 11:34 skrev Martin Sandve Alnæs <[email protected]>: > I think you're slightly changing the definition of 'dx' here, by > introducing the > concepts 'uncut', 'visible', which are defined in terms of another > (unknown) mesh. > > f*dx(3, mesh) <-- does not contain information about the other mesh > > However I trust that it will work out, this is an iterative process. > Worst case is that dX cannot be used in some scenarios. > > Btw, can you please use the word 'subdomain' instead of 'domain' here, > the ufl concepts use the names dx(subdomain_id=3, domain=mesh). > > Martin > > > > On 20 October 2015 at 11:16, Anders Logg <[email protected]> wrote: > >> 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
