I just want the definition to be clear when this functionality and interface has matured.
In particular for two functionals M1 and M2: assert assemble(M1+M2) == assemble(M1) + assemble(M2) # within floating point precision of course should always hold, i.e. adding M2 to M1 shouldn't change which cells M1 is integrated over by moving to a 'in the case of multiple meshes'. Martin On 20 October 2015 at 11:50, Anders Logg <anders.l...@gmail.com> wrote: > 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 <marti...@simula.no>: > >> 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 <anders.l...@gmail.com> 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 <marti...@simula.no >>> >: >>> >>>> 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 fenics@fenicsproject.org http://fenicsproject.org/mailman/listinfo/fenics
