From: Sylvain V. <svallagh@MIT.EDU> - 2012-02-08 22:07:30
|
Hi, I'm trying to implement a 2d problem in libmesh where I have two scalar variables : one is 2d in the whole domain, the other is 1d and mapped on one of the boundaries of my domain. These two variables are coupled due to the global variational formulation. I don't know how to define my 1d variable so that it can be part of the equation_systems (since it is based on a 2d mesh). In the examples I've seen so far, problems with multiple variables all have the same dimension (e.g. Stokes). Any help would be much appreciated. Thanks, Sylvain |
From: David K. <dkn...@se...> - 2012-02-08 22:44:33
|
On 02/08/2012 05:07 PM, Sylvain Vallaghe wrote: > I'm trying to implement a 2d problem in libmesh where I have two scalar variables : one is 2d in the whole domain, the other is 1d and mapped on one of the boundaries of my domain. These two variables are coupled due to the global variational formulation. I don't know how to define my 1d variable so that it can be part of the equation_systems (since it is based on a 2d mesh). In the examples I've seen so far, problems with multiple variables all have the same dimension (e.g. Stokes). > Any help would be much appreciated. An EquationSystems object is tied to a Mesh, so it seems like you'd have to have two separate EquationSystems. But this would necessitate some sort of "loose coupling," which maybe you were hoping to avoid? Note that you can extract a boundary mesh using BoundaryMesh boundary_mesh(dim-1); mesh.boundary_info->sync(requested_boundary_ids, boundary_mesh); David |
From: Mauro W. <m_w...@sf...> - 2012-02-08 23:09:23
|
I've never done it but here my thoughts: It should be possible to assemble the 1D system when looping over the boundary elements of the 2D mesh (as is usually done for the BCs) as all the machinery is in place to do this. Mauro At Wed, 8 Feb 2012 22:07:16 +0000, Sylvain Vallaghe wrote: > > Hi, > > I'm trying to implement a 2d problem in libmesh where I have two scalar variables : one is 2d in the whole domain, the other is 1d and mapped on one of the boundaries of my domain. These two variables are coupled due to the global variational formulation. I don't know how to define my 1d variable so that it can be part of the equation_systems (since it is based on a 2d mesh). In the examples I've seen so far, problems with multiple variables all have the same dimension (e.g. Stokes). > Any help would be much appreciated. > Thanks, > > Sylvain > ------------------------------------------------------------------------------ > Keep Your Developer Skills Current with LearnDevNow! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-d2d > _______________________________________________ > Libmesh-users mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libmesh-users |
From: David K. <dkn...@se...> - 2012-02-08 23:37:06
|
On 02/08/2012 06:09 PM, Mauro Werder wrote: > I've never done it but here my thoughts: It should be possible to > assemble the 1D system when looping over the boundary elements of the > 2D mesh (as is usually done for the BCs) as all the machinery is in > place to do this. All the machinery is there in the sense that you can already evaluate shape functions on boundaries (as in BC assembly), but you'd need to be able to add a "boundary-only variable" to have the correct number of degrees of freedom for the 1D variable. Maybe this could be implemented similarly to the "subdomain-only variables"? > > At Wed, 8 Feb 2012 22:07:16 +0000, > Sylvain Vallaghe wrote: >> Hi, >> >> I'm trying to implement a 2d problem in libmesh where I have two scalar variables : one is 2d in the whole domain, the other is 1d and mapped on one of the boundaries of my domain. These two variables are coupled due to the global variational formulation. I don't know how to define my 1d variable so that it can be part of the equation_systems (since it is based on a 2d mesh). In the examples I've seen so far, problems with multiple variables all have the same dimension (e.g. Stokes). >> Any help would be much appreciated. >> Thanks, >> >> Sylvain >> ------------------------------------------------------------------------------ >> Keep Your Developer Skills Current with LearnDevNow! >> The most comprehensive online learning library for Microsoft developers >> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, >> Metro Style Apps, more. Free future releases when you subscribe now! >> http://p.sf.net/sfu/learndevnow-d2d >> _______________________________________________ >> Libmesh-users mailing list >> Lib...@li... >> https://lists.sourceforge.net/lists/listinfo/libmesh-users > ------------------------------------------------------------------------------ > Virtualization& Cloud Management Using Capacity Planning > Cloud computing makes use of virtualization - but cloud computing > also focuses on allowing computing to be delivered as a service. > http://www.accelacomm.com/jaw/sfnl/114/51521223/ > _______________________________________________ > Libmesh-users mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libmesh-users |
From: Roy S. <roy...@ic...> - 2012-02-09 01:14:46
|
On Wed, 8 Feb 2012, David Knezevic wrote: > On 02/08/2012 06:09 PM, Mauro Werder wrote: >> I've never done it but here my thoughts: It should be possible to >> assemble the 1D system when looping over the boundary elements of the >> 2D mesh (as is usually done for the BCs) as all the machinery is in >> place to do this. > > All the machinery is there in the sense that you can already evaluate > shape functions on boundaries (as in BC assembly), but you'd need to be > able to add a "boundary-only variable" to have the correct number of > degrees of freedom for the 1D variable. Maybe this could be implemented > similarly to the "subdomain-only variables"? Only with some difficulty; it'd be the first time we put variables on elements that didn't technically exist. It'd be easier (though still quite difficult) to do something we've been wanting to for a while: extend libMesh to handle Mesh objects with Elems of more than one dimension inside. Then you just create the boundary mesh, add those elements into the Mesh with their own subdomain, set a per-subdomain variable on for them, and off you go. --- Roy |
From: Derek G. <fri...@gm...> - 2012-02-09 16:19:13
|
On Feb 8, 2012, at 6:14 PM, Roy Stogner wrote: > Only with some difficulty; it'd be the first time we put variables on > elements that didn't technically exist. > > It'd be easier (though still quite difficult) to do something we've > been wanting to for a while: extend libMesh to handle Mesh objects > with Elems of more than one dimension inside. Then you just create > the boundary mesh, add those elements into the Mesh with their own > subdomain, set a per-subdomain variable on for them, and off you go. Are you sure this does't work right now? We are using lower dimension meshes in higher dimension spaces right now… and I can't see why having some elements that are 2D and some that are 1D in the same mesh wouldn't work. You might even be able to tie them together by using the same nodes (so that the solutions are continuous and the sparsity pattern is correct). You might not be able to read this mesh from a file (although I think Exodus supports it). But if you just manually add a 2D element to a mesh and then add a 1D element… why wouldn't it work? If you give them different subdomains then you should even be able to restrict variables to the different pieces. Derek |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2012-02-09 16:26:08
|
> You might even be able to tie them together by using the same nodes (so that > the solutions are continuous and the sparsity pattern is correct). > > You might not be able to read this mesh from a file (although I think Exodus > supports it). But if you just manually add a 2D element to a mesh and then > add a 1D elementŠ why wouldn't it work? If you give them different subdomains > then you should even be able to restrict variables to the different pieces. I don't think there is anything fundamental that will keep it from working, but you'll have to be careful in user code. Right now if you just iterate over all the elements in the mesh and call fe->reinit(elem) I think the underlying FE and Quadrature rules are expecting all the same dimension. Of course you could get around this by manually creating multiple FE objects and calling the right one, but that is a hassle that would be nice to avoid. And I'm not sure how broken this is currently (if at all?) - perhaps just overzealous asserts... -Ben |
From: Sylvain V. <svallagh@MIT.EDU> - 2012-02-09 16:56:03
|
I've tried reading from a gmsh file, and it reads only the 1d elements and then stops (although there are 2d elements in the following lines of the file). I'm gonna try to add 1d elements manually and see if it works. Thanks for all the replies. Sylvain ________________________________________ From: Derek Gaston [fri...@gm...] Sent: Thursday, February 09, 2012 11:18 AM To: Roy Stogner Cc: lib...@li... Subject: Re: [Libmesh-users] Coupling variables with different dimensions On Feb 8, 2012, at 6:14 PM, Roy Stogner wrote: > Only with some difficulty; it'd be the first time we put variables on > elements that didn't technically exist. > > It'd be easier (though still quite difficult) to do something we've > been wanting to for a while: extend libMesh to handle Mesh objects > with Elems of more than one dimension inside. Then you just create > the boundary mesh, add those elements into the Mesh with their own > subdomain, set a per-subdomain variable on for them, and off you go. Are you sure this does't work right now? We are using lower dimension meshes in higher dimension spaces right now… and I can't see why having some elements that are 2D and some that are 1D in the same mesh wouldn't work. You might even be able to tie them together by using the same nodes (so that the solutions are continuous and the sparsity pattern is correct). You might not be able to read this mesh from a file (although I think Exodus supports it). But if you just manually add a 2D element to a mesh and then add a 1D element… why wouldn't it work? If you give them different subdomains then you should even be able to restrict variables to the different pieces. Derek ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ _______________________________________________ Libmesh-users mailing list Lib...@li... https://lists.sourceforge.net/lists/listinfo/libmesh-users |
From: Roy S. <roy...@ic...> - 2012-02-09 16:28:47
|
On Thu, 9 Feb 2012, Derek Gaston wrote: > On Feb 8, 2012, at 6:14 PM, Roy Stogner wrote: > >> Only with some difficulty; it'd be the first time we put variables on >> elements that didn't technically exist. >> >> It'd be easier (though still quite difficult) to do something we've >> been wanting to for a while: extend libMesh to handle Mesh objects >> with Elems of more than one dimension inside. Then you just create >> the boundary mesh, add those elements into the Mesh with their own >> subdomain, set a per-subdomain variable on for them, and off you go. > > Are you sure this does't work right now? We are using lower > dimension meshes in higher dimension spaces right now… Lower dimension meshes in higher dimension spaces should definitely work; we've also been using them for a while and I only recall finding (and fixing) one or two bugs before we started getting good results. > and I can't see why having some elements that are 2D and some that > are 1D in the same mesh wouldn't work. There are lots of places where we build an FEBase object of mesh_dimension() and then assume that we can use it on every element, for starters. > You might even be able to tie them together by using the same nodes > (so that the solutions are continuous and the sparsity pattern is > correct). This is a great idea but would almost certainly break on find_neighbors(). --- Roy |
From: Derek G. <fri...@gm...> - 2012-02-09 16:34:38
|
On Feb 9, 2012, at 9:28 AM, Roy Stogner wrote: > There are lots of places where we build an FEBase object of > mesh_dimension() and then assume that we can use it on every element, > for starters. Well… of course the user doing this would have to be aware of what they are doing and do the right thing. > This is a great idea but would almost certainly break on > find_neighbors(). Interesting - I hadn't thought of that. Well, if find_neighbors() breaks you should still be able to have a separate piece of the mesh that is 1D and copy values back and forth between the two pieces. You can even add more entries to the sparsity pattern and send_list so that it "ties" the two pieces of the mesh together. The reason I'm in this discussion is that we're going to be doing something similar soon. Derek |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2012-02-09 16:48:33
|
>> This is a great idea but would almost certainly break on >> find_neighbors(). > > Interesting - I hadn't thought of that. Well, if find_neighbors() breaks you > should still be able to have a separate piece of the mesh that is 1D and copy > values back and forth between the two pieces. You can even add more entries > to the sparsity pattern and send_list so that it "ties" the two pieces of the > mesh together. > > The reason I'm in this discussion is that we're going to be doing something > similar soon. This would be easily fixable by putting an outer loop over the dimensions of the elements in the mesh around the current find_neighbors to force elements to look at only elements of the same dimension. So it would probably also be nice to have a method in the mesh to return a set of all the dimensions it contains... Now if you want the lower dimensional element to know which higher dimensional element it is congruent with then that would take some extra doing... This would be cool though, it could easily replace the boundary_mesh hackery we currently do for postprocessing. -Ben |
From: Roy S. <roy...@ic...> - 2012-02-09 16:50:10
|
On Thu, 9 Feb 2012, Derek Gaston wrote: > On Feb 9, 2012, at 9:28 AM, Roy Stogner wrote: > >> There are lots of places where we build an FEBase object of >> mesh_dimension() and then assume that we can use it on every element, >> for starters. > > Well… of course the user doing this would have to be aware of what they are doing and do the right thing. Who said "the user"? Sadly I really did mean "we". See System::project_*, System::calculate_norm, EquationSystems::build_*solution_vector, FEMContext, MeshFunction, and practically everything in src/error_estimation/ or src/mesh/*io.C There are places where we appear to do things right (e.g. the constraints code) but I'm sure it was by accident rather than by design. ;-) > Interesting - I hadn't thought of that. Well, if find_neighbors() > breaks you should still be able to have a separate piece of the mesh > that is 1D and copy values back and forth between the two pieces. > You can even add more entries to the sparsity pattern and send_list > so that it "ties" the two pieces of the mesh together. This is probably the way you'd have to go. find_neighbors() was always the big sticking point for me: I figured that if we were ever going to support any really *interesting* multidimensional meshes, then it would have to include things like a hex neighboring a quad, or three quad shell elementss meeting in a "Y" shape, and I couldn't even figure out how to tweak our *data structures* to support that properly, much less the algorithm. > The reason I'm in this discussion is that we're going to be doing > something similar soon. Ah; in that case the reason I'm staying in this discussion is to try and talk you guys into fixing all that multi-manifold-incompatible stuff I listed above. ;-) I think find_neighbors() is a lost cause, but supporting conceptually disjoint manifolds of different dimensions, manually "tied" together, ought to be doable after the FEBase::build(mesh_dimension, blah) stuff is fixed. Ben, why is the FE class dimension-dependent to begin with? All the calculations need to take place in LIBMESH_DIM dimensions anyway, except the ones which are Elem-subclass-dependent and could therefore switch on Elem::dimension instead. --- Roy |