| Thread Previous • Date Previous • Date Next • Thread Next |
On Jul 15, 2009, at 1:27 PM, Anders Logg wrote:
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 theintended 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 forgottenwhile 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 whenit'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.
Will do...
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.
In the case of completely overlapping meshes, it's also useful as a way of marking internal boundaries (as the subdomain.inside can then include && on_boundary). I need to impose some internal Dirichlet conditions on the edges of the sub-domain (which is rather irregularly shaped and I wasn't sure how to do that with restriction (but maybe that get's picked up during assembly)
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.
Sounds good. I'll just keep reading dolfin-dev and see where it all goes...If I have any marginally useful ideas I'll try to post them
cheers marc
-- AndersOn 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 thismake 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 onlyshare 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/issues1) 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 thebest way to do this would be...a nice interface would be similar toFunctionSpace.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 designedfor 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 embeddedmulti-physics problems. Thanks again marc ? Garth All help greatly appreciated as always cheers marc p.s. all current dev repositoriesp.p.s. another official release would be great...a lot has changedsince 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_______________________________________________ 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) ----------------------------------------------------
| Thread Previous • Date Previous • Date Next • Thread Next |
