On Tue, Feb 22, 2011 at 11:32:07AM +0000, Garth N. Wells wrote: > > > On 22/02/11 11:07, Anders Logg wrote: > > On Tue, Feb 22, 2011 at 08:52:55AM +0000, Garth N. Wells wrote: > >> > >> > >> On 22/02/11 07:51, Anders Logg wrote: > >>> I'd like to implement this blueprint for 0.9.10: > >>> > >>> https://blueprints.launchpad.net/dolfin/+spec/attach-subdomains-to-form > >>> > >>> In addition, I'd like to remove the cell_domains, > >>> exterior_facet_domains and interior_facet_domains arguments from the > >>> assembler. It seems overkill to have three different ways to specify > >>> the domains and the logic becomes complex for handling which data > >>> overrides if many are specified. We could also remove these arguments > >>> from VariationalProblem. > >>> > >>> We would then have two ways to specify the subdomains: > >>> > >>> 1. As part of the Mesh (MeshData) > >>> > >>> 2. As part of the form > >>> > >>> The SystemAssembler would then need to rely on (1). > >>> > >>> Comments and objections? > >>> > >> > >> What's the advantage of having two methods? Why not just have one? > > > > It's natural to specify the subdomains as part of the mesh, but it's > > also natural to specify them as part of the form if one has say a and > > L and they should be assembled on the same mesh but partition the > > domain differently into subdomains. > > > > OK.
I will implement this then. -- Anders > >> I'd would be happy to see subdomains as part of MeshData, but I would be > >> reluctant to use the existing data structures because I find them cryptic. > > > > I agree they are cryptic but it's the only way I know how to robustly > > specify the boundaries. We can't store just a FacetFunction since the > > facet numbering relies on the particular algorithm we use to compute > > the facets (in TopologyComputation). If we optimize that computation, > > the numbering may very well change. > > > > What we do now is to specify a certain facet on a certain cell of the > > mesh. That is robust as long as the cell-vertex number does not change. > > > > I don't quite follow the above. I advocate that the we have something like > > std::vector<MeshFunction<uint> > sub_domains; > > in MeshData where the size of sub_domains is equal to the topological > dimension. By being explicit in MeshData, it's much clearer what needs > to be updated or reset if a mesh is changed. > > > >> We could have cell domains become part of the mesh .xml files - this > >> would be helpful because mesh generators can often define domains, and > >> it would be handy to use this data easily (by supporting it in > >> dolfin-convert). > > > > Isn't it already? Everything stored in MeshData will automatically be > > stored/retrieved from XML. > > > > It may be, but I don't think that dolfin-convert supports it. > > Garth > > _______________________________________________ Mailing list: https://launchpad.net/~dolfin Post to : dolfin@lists.launchpad.net Unsubscribe : https://launchpad.net/~dolfin More help : https://help.launchpad.net/ListHelp
