Yes of course. Agreed. -- Anders
tis 20 okt. 2015 kl 12:06 skrev Martin Sandve Alnæs <marti...@simula.no>: > 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
