dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Wed, Jul 15, 2009 at 11:43:37AM -0400, mspieg wrote:
> Thanks Garth,
> 
> On Jul 15, 2009, at 10:44 AM, Garth N. Wells wrote:
> 
> 
> 
> 
>     mspieg wrote:
> 
>         Hi All,
>            I think there is a bug when trying to read a MeshFunction from a
>         file that was generated on a SubMesh.  I've attached some python based
>         on the SubMesh demo, that demonstrates the problem.  I think the issue
>         is that there is an extra MeshFunction embedded in a SubMesh to
>         describe the "global vertex indices" that gets read instead of the
>         intended mesh-function.  
> 
> 
>     It might be a while before anyone gets to this. We hope to have a new,
>     simple to use bug tracking system (i.e. not Bugzilla) in place soon to keep
>     track of these types of issues, especially since they tend to be forgotten
>     while everyone is on holiday.
> 
> 
> 
> That would be good.  I can work around this easily enough at the moment (if I
> just strip out the unwanted MeshFunction from the file everything works fine).
>  If I don't see a fix, I'll post something on the new bug tracking system when
> it's in place.

Yes, posting this as a bug would be a good idea. The new bug tracking
system (Roundup, same as Python uses) will be in place after the
holiday so keep this in mind until then.

The SubMesh class only helps you with creating new meshes based on a
global mesh and some sub domain markers. It only provides a mapping
from the vertex numbers of the extracted sub meshes to the vertex
numbers on the original mesh. So in that sense it does less than the
restriction does. We use it for FSI.

Kent implemented the restriction and I implemented the SubMesh
class. They sort of solve the same problem but in different ways. It's
a good point that there could be more coordination between the two
designs. Something for the todo list.

-- 
Anders


> 
> 
>         On a related note, it's easy enough to extract a SubMesh from a larger
>         Mesh using a MeshFunction, but what is the best way to extract just the
>         piece of a discrete function on the SubMesh, when the Function is
>         originally defined for a Function Space on the larger mesh. (does this
>         make sense?)
>         These issues arise from a multiphysics problem that I'm working with
>         overlapping domains  where I basically want to solve an embedded porous
>         media problem on a subdomain of a larger stokes flow (this is slightly
>         different from the fluid-structure demo where the two domains only
>         share a boundary.)
> 
> 
>     Kent has been working on something like this. Have you looked at
> 
>       demo/function/restriction
> 
> 
> I started to look at this...A couple of questions/issues 
> 
> 1) at the moment restriction only takes MeshFunction<bool> whereas SubMesh
> takes (MeshFunction<uint>,uint) which allows multiple subdomains.  It might be
> nice if these two had similar interfaces particularly since I think it makes
> more sense to use SubMesh to apply boundary conditions on the subdomain.
> 
> 2) At the moment restriction seems to mainly apply to the function space, not
> the function (i.e. the demo just creates a new function on the restricted
> function space, not extracts a restricted function from the larger space).  I
> suspect this wouldn't be too hard to do, but it's not entirely obvious what the
> best way to do this would be...a nice interface would be similar to
> FunctionSpace.restriction()  something like F=Function(V), F_restricted=
> F.restriction(MeshFunction<?>)
> 
> 3) I have no idea how to handle this in parallel (but a lot of these issues are
> related to local<->global mappings and maybe something can be cleanly designed
> for all of these problems)
> 
> Like I said, I can work around all of this at the moment, but it would be
> useful to think through the best way to deal with these sorts of embedded
> multi-physics problems.
> 
> Thanks again
> marc
> 
> 
> 
> 
>     ?
> 
>     Garth
> 
> 
>         All help greatly appreciated as always
>         cheers
>         marc
>         p.s. all current dev repositories
>         p.p.s. another official release would be great...a lot has changed
>         since 2009-04
>         ------------------------------------------------------------------------
>         ----------------------------------------------------
>         Marc Spiegelman
>         Lamont-Doherty Earth Observatory
>         Dept. of Applied Physics/Applied Math
>         Columbia University
>         http://www.ldeo.columbia.edu/~mspieg
>         tel: 845 704 2323 (SkypeIn)
>         ----------------------------------------------------
>         ------------------------------------------------------------------------
>         _______________________________________________
>         DOLFIN-dev mailing list
>         DOLFIN-dev@xxxxxxxxxx
>         http://www.fenics.org/mailman/listinfo/dolfin-dev
> 
> 
> ----------------------------------------------------
> Marc Spiegelman
> Lamont-Doherty Earth Observatory
> Dept. of Applied Physics/Applied Math
> Columbia University
> http://www.ldeo.columbia.edu/~mspieg
> tel: 845 704 2323 (SkypeIn)
> ----------------------------------------------------
> 
> 

> _______________________________________________
> DOLFIN-dev mailing list
> DOLFIN-dev@xxxxxxxxxx
> http://www.fenics.org/mailman/listinfo/dolfin-dev

Attachment: signature.asc
Description: Digital signature