On 3 September 2012 09:06, Marie E. Rognes <[email protected]> wrote: > On 09/02/2012 12:23 PM, Garth N. Wells wrote: >> >> On 2 September 2012 11:10, Anders Logg <[email protected]> wrote: >>> >>> On Sat, Sep 01, 2012 at 03:09:42PM +0100, Garth N. Wells wrote: >>>> >>>> The logic around how we handle integration over domains is confusing. >>>> I'm trying to fix a small problem which is opening a can of worms. >>>> Subdomain data can be optionally passed to the assembler, attached to >>>> a Form or attached to a Mesh (the latter being particularly confusing >>>> because it's mixing concepts). I suggest that we have just one to do >>>> things, and I think the most logical and user friendly is to attach >>>> subdomain data to Forms. Opinions? > > > Agree! > > >>> I agree that the logic is complex, but it is there for a reason. >>> >>> There are three ways to specify subdomains, by order of increasing >>> priority. >>> >>> First, it can be specified as part of the mesh. This is a good thing >>> since it allows markers to be stored as part of Mesh XML files. Very >>> useful for Mesh generators and tools like VMTK. >>> >> I think that this is very clumsy and mixes concepts. Say I have one >> mesh but want to perform two different simulations with different bcs. >> It's opaque. What happens if I have markers in a Mesh and markers >> attached to a Form -> ambiguous. >> >> Better would be to store the markers as part of the mesh, but pull >> them out and attach them to a form. I was already planning to have >> mesh markers in a mesh file that are identified by strings (e.g. >> "top", "inner sphere", etc) rather than integers (which are error >> prone because they convey no meaning). A user could query which >> markers a mesh has (via a set of identifier strings), and attach the >> right ones. > > > Yes, I would find this less confusing and more useful. >
Yes, I was getting confused. Also, I was trying convert a common 3rd party format the uses names for sub-domains. > >>> Second, it can be specified as part of a Form. This is useful for >>> assembling several forms on the same mesh but with different domains. >>> >> This is nice. >> >>> Third, it can be specified explicitly as an argument to the assembler. >>> >>> If we should cut any of these, I would suggest cutting the third one, >>> but I think it is widely used as part of both user code and examples >>> so I'm not sure we should cut it. >>> > > I think in order to cut the third one, there needs to be a reliable and > flexible way of replacing subdomains in a given form cf Johan's comment. > This might exist today, but I'm not entirely sure. > Should be easy via shared pointers. > > >> We have a bug that I'm more interested in fixing simply and robustly >> than in preserving a clumsy interface, so I'd cut it. Users can update >> their code. > > > Cutting this interface is a significant change, so I would suggest > adding a deprecation warning and making a release before doing so. > Could be tricky because the interface is the bug, due to ambiguities with all the default arguments. Garth > -- > Marie >> >> Garth >> >>> The logic for extracting which domains could be moved to a special >>> function that takes care of extracting the correct MeshFunction from >>> either Mesh, Form or explicit arguments. With some extra diagnostics >>> and careful error checking, it can be made more robust and >>> user-friendly. >>> >>> -- >>> Anders >> >> _______________________________________________ >> >> Mailing list: https://launchpad.net/~dolfin >> Post to : [email protected] >> Unsubscribe : https://launchpad.net/~dolfin >> More help : https://help.launchpad.net/ListHelp > > > > _______________________________________________ > Mailing list: https://launchpad.net/~dolfin > Post to : [email protected] > Unsubscribe : https://launchpad.net/~dolfin > More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~dolfin Post to : [email protected] Unsubscribe : https://launchpad.net/~dolfin More help : https://help.launchpad.net/ListHelp

