| Thread Previous • Date Previous • Date Next • Thread Next |
Hi Kent,and thanks for getting back...Everything you said sounds great. I'll keep my eyes open for changesets.
Many thanks marc On Jul 17, 2009, at 2:02 PM, kent-and@xxxxxxxxx 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.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/restrictionI started to look at this...A couple of questions/issuesSorry for not getting back on you before now.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.Agree, I'll do this.
Great.
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<?>)Something like this can be done, I agree. At least the mapping between the restricted and the full space should be exposed such that this is possible.
That would be great...I started to think through how to do this, but thought that any hack I do is bound to be fragile. I'm not entirely sure what you had in mind but it would seem that a mapping of indices between the full and restricted dofs could be useful for extracting the vector for the restricted function, directly from the larger function (e.g. something like PETSc's IndexSet IS). But I'll be interested to see how you do this.
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)I have no idea either :)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 marcAgree Kent? GarthAll 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
---------------------------------------------------- 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 |
