← Back to team overview

dolfin team mailing list archive

  1. dolfin team
  2. Mailing list archive
  3. Message #21879

Re: Blueprint for 0.9.10: Attaching subdomains to form

  Thread Previous • Date Previous • • Thread Next 
On 02/22/2011 08:35 PM, Anders Logg wrote:

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.



Looking forward to this... Is there an ETA ;-) ?

--
Marie




--
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@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~dolfin
More help   : https://help.launchpad.net/ListHelp

Follow ups

References

  Thread Previous • Date Previous • • Thread Next