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'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 > -- > Anders _______________________________________________ Mailing list: https://launchpad.net/~dolfin Post to : [email protected] Unsubscribe : https://launchpad.net/~dolfin More help : https://help.launchpad.net/ListHelp
