From: David K. <dkn...@se...> - 2013-08-18 23:21:01
|
DirichletBoundary objects currently work based on boundary IDs. I'd like to be able to use DirichletBoundary objects to impose boundary conditions on boundary nodes and/or edges of a mesh. The motivation is to use Node or Edge Dirichlet boundary conditions to impose boundary conditions in structural analysis that don't constrain rotation (e.g. to provide a simple way to model joints or pins). I guess the target Node or Edge could be identified by passing in multiple boundary IDs and imposing the BC on the nodes or edges that belong to all of those IDs. Would this be workable within the current DirichletBoundary framework (perhaps there are some issues since it presumably uses L2 project on boundaries...) and does this seem like a change of general interest? If so, I'm happy to work on it. Thanks, David |
From: Roy S. <roy...@ic...> - 2013-08-19 02:38:56
|
On Mon, 19 Aug 2013, David Knezevic wrote: > DirichletBoundary objects currently work based on boundary IDs. I'd like > to be able to use DirichletBoundary objects to impose boundary > conditions on boundary nodes and/or edges of a mesh. > > The motivation is to use Node or Edge Dirichlet boundary conditions to > impose boundary conditions in structural analysis that don't constrain > rotation (e.g. to provide a simple way to model joints or pins). Makes perfect sense. > I guess the target Node or Edge could be identified by passing in > multiple boundary IDs and imposing the BC on the nodes or edges that > belong to all of those IDs. We have boundary IDs that apply to nodes though, don't we? I wonder if the right thing to do isn't just to add the same structure for edges and then make the dirichlet constraints code take notice. > Would this be workable within the current DirichletBoundary framework > (perhaps there are some issues since it presumably uses L2 project on > boundaries...) For parallel consistency we actually do: 1. Interpolate at nodes 2. L2 project any edge degrees of freedom left over when holding node dofs fixed 3. L2 project any face dofs left over when holding node and edge dofs fixed So it'd actually be relatively straightforward to mix node and edge dirichlet conditions into that. > and does this seem like a change of general interest? If so, I'm > happy to work on it. I'm currently cringing because I have an unmerged branch that edits a ton of dirichlet constraints code to handle adjoint problems with heterogeneous Dirichlet boundaries, and I don't want a mess of merge conflicts. It's passing make check, though, so I suppose I can turn it into a pull request even though it's not feature complete. As luck would have it, I already made all the changes that might have caused conflicts. --- Roy |
From: David K. <dkn...@se...> - 2013-08-19 06:00:51
|
On 08/19/2013 04:38 AM, Roy Stogner wrote: > > On Mon, 19 Aug 2013, David Knezevic wrote: > >> DirichletBoundary objects currently work based on boundary IDs. I'd like >> to be able to use DirichletBoundary objects to impose boundary >> conditions on boundary nodes and/or edges of a mesh. >> >> The motivation is to use Node or Edge Dirichlet boundary conditions to >> impose boundary conditions in structural analysis that don't constrain >> rotation (e.g. to provide a simple way to model joints or pins). > > Makes perfect sense. > >> I guess the target Node or Edge could be identified by passing in >> multiple boundary IDs and imposing the BC on the nodes or edges that >> belong to all of those IDs. > > We have boundary IDs that apply to nodes though, don't we? I wonder > if the right thing to do isn't just to add the same structure for > edges and then make the dirichlet constraints code take notice. This approach would be great, I think. I haven't used boundary IDs that apply to nodes before. I guess you're referring to "nodesets" in BoundaryInfo? That looks convenient. > >> Would this be workable within the current DirichletBoundary framework >> (perhaps there are some issues since it presumably uses L2 project on >> boundaries...) > > For parallel consistency we actually do: > 1. Interpolate at nodes > 2. L2 project any edge degrees of freedom left over when holding node > dofs fixed > 3. L2 project any face dofs left over when holding node and edge dofs > fixed > > So it'd actually be relatively straightforward to mix node and edge > dirichlet conditions into that. OK, great! > >> and does this seem like a change of general interest? If so, I'm >> happy to work on it. > > I'm currently cringing because I have an unmerged branch that edits a > ton of dirichlet constraints code to handle adjoint problems with > heterogeneous Dirichlet boundaries, and I don't want a mess of merge > conflicts. > > It's passing make check, though, so I suppose I can turn it into a > pull request even though it's not feature complete. As luck would > have it, I already made all the changes that might have caused > conflicts. No rush. I'd rather wait until you merge your branch. Best, David |
From: David K. <dkn...@se...> - 2013-10-07 14:57:36
|
Hi Roy, I'd like to work on the "DirchletBoundary on nodes" issue that we discussed below. You mentioned that you have an unmerged branch that I should wait for. What's the status of that now? Thanks, David On 08/18/2013 10:38 PM, Roy Stogner wrote: > > On Mon, 19 Aug 2013, David Knezevic wrote: > >> DirichletBoundary objects currently work based on boundary IDs. I'd like >> to be able to use DirichletBoundary objects to impose boundary >> conditions on boundary nodes and/or edges of a mesh. >> >> The motivation is to use Node or Edge Dirichlet boundary conditions to >> impose boundary conditions in structural analysis that don't constrain >> rotation (e.g. to provide a simple way to model joints or pins). > > Makes perfect sense. > >> I guess the target Node or Edge could be identified by passing in >> multiple boundary IDs and imposing the BC on the nodes or edges that >> belong to all of those IDs. > > We have boundary IDs that apply to nodes though, don't we? I wonder > if the right thing to do isn't just to add the same structure for > edges and then make the dirichlet constraints code take notice. > >> Would this be workable within the current DirichletBoundary framework >> (perhaps there are some issues since it presumably uses L2 project on >> boundaries...) > > For parallel consistency we actually do: > 1. Interpolate at nodes > 2. L2 project any edge degrees of freedom left over when holding node > dofs fixed > 3. L2 project any face dofs left over when holding node and edge dofs > fixed > > So it'd actually be relatively straightforward to mix node and edge > dirichlet conditions into that. > >> and does this seem like a change of general interest? If so, I'm >> happy to work on it. > > I'm currently cringing because I have an unmerged branch that edits a > ton of dirichlet constraints code to handle adjoint problems with > heterogeneous Dirichlet boundaries, and I don't want a mess of merge > conflicts. > > It's passing make check, though, so I suppose I can turn it into a > pull request even though it's not feature complete. As luck would > have it, I already made all the changes that might have caused > conflicts. > --- > Roy |
From: Roy S. <roy...@ic...> - 2013-10-07 16:10:02
|
On Mon, 7 Oct 2013, David Knezevic wrote: > I'd like to work on the "DirchletBoundary on nodes" issue that we discussed > below. > > You mentioned that you have an unmerged branch that I should wait for. What's > the status of that now? The new feature needs massive work (I basically need to trash a third of the new code and rewrite the same functionality in a different place in a different way) but the data structures and refactoring to enable it should be entirely solid now. Go ahead and run https://github.com/libMesh/libmesh/pull/141 through some tests, and feel free to either base off of it or merge it if it's working for you. --- Roy |
From: Roy S. <roy...@ic...> - 2013-10-07 22:36:31
|
On Mon, 7 Oct 2013, Roy Stogner wrote: > > On Mon, 7 Oct 2013, David Knezevic wrote: > >> I'd like to work on the "DirchletBoundary on nodes" issue that we discussed >> below. >> >> You mentioned that you have an unmerged branch that I should wait for. >> What's the status of that now? > > The new feature needs massive work (I basically need to trash a third > of the new code and rewrite the same functionality in a different > place in a different way) but the data structures and refactoring to > enable it should be entirely solid now. And I'm about to potentially invalidate that claim as of my next commit... > Go ahead and run https://github.com/libMesh/libmesh/pull/141 through > some tests, and feel free to either base off of it or merge it if > it's working for you. Let me know how your tests go, but don't merge yet; I want to re-run it through my own tests again first. --- Roy |
From: David K. <dkn...@se...> - 2013-10-07 22:37:17
|
On 10/07/2013 06:36 PM, Roy Stogner wrote: > > > On Mon, 7 Oct 2013, Roy Stogner wrote: > >> >> On Mon, 7 Oct 2013, David Knezevic wrote: >> >>> I'd like to work on the "DirchletBoundary on nodes" issue that we >>> discussed below. >>> >>> You mentioned that you have an unmerged branch that I should wait >>> for. What's the status of that now? >> >> The new feature needs massive work (I basically need to trash a third >> of the new code and rewrite the same functionality in a different >> place in a different way) but the data structures and refactoring to >> enable it should be entirely solid now. > > And I'm about to potentially invalidate that claim as of my next > commit... > >> Go ahead and run https://github.com/libMesh/libmesh/pull/141 through >> some tests, and feel free to either base off of it or merge it if >> it's working for you. > > Let me know how your tests go, but don't merge yet; I want to re-run > it through my own tests again first. OK, I haven't got around to starting on this yet, so I'll hold off for a bit anyway. Thanks, Dave |
From: David K. <dkn...@se...> - 2013-10-08 19:43:28
|
Hi Roy, >> Go ahead and run https://github.com/libMesh/libmesh/pull/141 through >> some tests, and feel free to either base off of it or merge it if >> it's working for you. > > Let me know how your tests go, but don't merge yet; I want to re-run > it through my own tests again first. I just pulled this branch. It's giving me compilation errors with --enable-complex (see below). Also, I got a segfault with an app with real numbers. I can provide more details about that shortly. David /home/dknez/software/libmesh-src/src/base/dof_map_constraints.C: In member function 'void libMesh::DofMap::allgather_recursive_constraints(libMesh::MeshBase&)': /home/dknez/software/libmesh-src/src/base/dof_map_constraints.C:2441:32: error: could not convert 'pushed_rhss_to_me.std::__debug::vector<_Tp, _Allocator>::operator[]<std::complex<double>, std::allocator<std::complex<double> > >(i)' from 'std::complex<double>' to 'bool' /home/dknez/software/libmesh-src/src/base/dof_map_constraints.C:2744:27: error: could not convert 'dof_filled_rhss.std::__debug::vector<_Tp, _Allocator>::operator[]<std::complex<double>, std::allocator<std::complex<double> > >(i)' from 'std::complex<double>' to 'bool' /home/dknez/software/libmesh-src/src/base/dof_map_constraints.C: In member function 'void libMesh::DofMap::process_constraints(libMesh::MeshBase&)': /home/dknez/software/libmesh-src/src/base/dof_map_constraints.C:2863:31: error: could not convert 'constraint_rhs' from 'libMesh::Number {aka std::complex<double>}' to 'bool' /home/dknez/software/libmesh-src/src/base/dof_map_constraints.C:2870:31: error: could not convert 'constraint_rhs' from 'libMesh::Number {aka std::complex<double>}' to 'bool' /home/dknez/software/libmesh-src/src/base/dof_map_constraints.C: In member function 'void libMesh::DofMap::scatter_constraints(libMesh::MeshBase&)': /home/dknez/software/libmesh-src/src/base/dof_map_constraints.C:3113:32: error: could not convert 'pushed_rhss_to_me.std::__debug::vector<_Tp, _Allocator>::operator[]<std::complex<double>, std::allocator<std::complex<double> > >(i)' from 'std::complex<double>' to 'bool' /home/dknez/software/libmesh-src/src/base/dof_map_constraints.C:3292:32: error: could not convert 'pushed_rhss_to_me.std::__debug::vector<_Tp, _Allocator>::operator[]<std::complex<double>, std::allocator<std::complex<double> > >(i)' from 'std::complex<double>' to 'bool' |
From: Roy S. <roy...@ic...> - 2013-10-08 20:37:32
|
On Tue, 8 Oct 2013, David Knezevic wrote: > I just pulled this branch. It's giving me compilation errors with > --enable-complex (see below). Thanks! I forgot that there's no implicit complex->bool conversion like there is with float/double/etc. Embarrassing but easy to fix. > Also, I got a segfault with an app with real numbers. I can provide more > details about that shortly. That sounds much more embarrassing and much harder to fix. I'm starting my own retesting now, but if I can't trigger anything I'll certainly be eager to help fix whatever you've managed to catch. --- Roy |
From: David K. <dkn...@se...> - 2013-10-08 22:41:56
|
On 10/08/2013 04:37 PM, Roy Stogner wrote: > > On Tue, 8 Oct 2013, David Knezevic wrote: > >> I just pulled this branch. It's giving me compilation errors with >> --enable-complex (see below). > > Thanks! I forgot that there's no implicit complex->bool conversion > like there is with float/double/etc. Embarrassing but easy to fix. OK, thanks, I'll try to build this with --enable-complex again later (I see that you pushed a fix). > >> Also, I got a segfault with an app with real numbers. I can provide >> more details about that shortly. > > That sounds much more embarrassing and much harder to fix. I'm > starting my own retesting now, but if I can't trigger anything I'll > certainly be eager to help fix whatever you've managed to catch. It wasn't a segfault actually. The solver was crashing, reporting that there was a NaN in the matrix. I reverted to e1167380e6872c6dbf2e487d4908be192caa21e3 and it still didn't work. Then I reverted to 99edb484698f647358c539df5a229503147bcdfd and it worked again. I'll continue with the binary search... David |
From: Roy S. <roy...@ic...> - 2013-10-08 23:08:59
|
On Tue, 8 Oct 2013, David Knezevic wrote: > It wasn't a segfault actually. The solver was crashing, reporting that there > was a NaN in the matrix. > > I reverted to e1167380e6872c6dbf2e487d4908be192caa21e3 and it still didn't > work. Then I reverted to 99edb484698f647358c539df5a229503147bcdfd and it > worked again. > > I'll continue with the binary search... Hmm... not sure a binary search is going to be helpful here. This change required a major refactor, and then lots of the subsequent changes are small bugfixes in that. Testing feature by feature might help. I assume your failure case uses AMR and/or Dirichlet BCs? Does it fail in serial? If you print the dof constraints for a working case vs the branch head, are there differences? --- Roy |
From: David K. <dkn...@se...> - 2013-10-09 01:37:17
|
On 10/08/2013 07:08 PM, Roy Stogner wrote: > > On Tue, 8 Oct 2013, David Knezevic wrote: > >> It wasn't a segfault actually. The solver was crashing, reporting >> that there was a NaN in the matrix. >> >> I reverted to e1167380e6872c6dbf2e487d4908be192caa21e3 and it still >> didn't work. Then I reverted to >> 99edb484698f647358c539df5a229503147bcdfd and it worked again. >> >> I'll continue with the binary search... > > Hmm... not sure a binary search is going to be helpful here. This > change required a major refactor, and then lots of the subsequent > changes are small bugfixes in that. > > Testing feature by feature might help. I assume your failure case > uses AMR and/or Dirichlet BCs? Does it fail in serial? If you print > the dof constraints for a working case vs the branch head, are there > differences? False alarm. The problem was at my end, sorry! Looks like it's working fine for me for the real-valued case. However, I still get compilation errors with --enable-complex (on eb4d88f). Have you tested this? Tomorrow I'll start looking at the topic in the subject line: DirichletBoundary on nodes. Do you have any suggestions on how I should get started? I think the key point from your original email was this: "For parallel consistency we actually do: 1. Interpolate at nodes 2. L2 project any edge degrees of freedom left over when holding node dofs fixed 3. L2 project any face dofs left over when holding node and edge dofs fixed " Thanks, David |
From: Roy S. <roy...@ic...> - 2013-10-09 14:26:11
|
On Tue, 8 Oct 2013, David Knezevic wrote: > However, I still get compilation errors with --enable-complex (on eb4d88f). > Have you tested this? No; I just replaced the "complex won't implicitly convert to bool" problem with an "int won't implicitly convert to complex" problem. I'm replacing that with an explicit conversion and testing the --enable-complex build now. > DirichletBoundary on nodes. Do you have any suggestions on how I should get > started? I think the key point from your original email was this: > > "For parallel consistency we actually do: > 1. Interpolate at nodes > 2. L2 project any edge degrees of freedom left over when holding node > dofs fixed > 3. L2 project any face dofs left over when holding node and edge dofs > fixed " That key point relates to the constraint equation algorithm, though... but I guess that's the only hard part? I think that the first thing I'd upgrade for dirichlet nodes and edges would be the API (very straightforward "add_foo(ForwardDeclaredFoo&)" declarations); next the data structures (no modifications necessary if we go the "use boundary ids corresponding to nodes and edges" route), finally the algorithms (not too hard once the data structures are done). No, scratch that. The very first thing I'd do is add "boundary ids that apply to edges" support. As to the algorithm... cross your fingers, but I suspect that with the current refactoring all you'd have to do is upgrade the "do_this_side", "is_boundary_node[n]" and "is_boundary_edge[e]" calculations in ConstrainDirichlet::apply_dirichlet_impl and you'll be done. --- Roy |
From: David K. <dkn...@se...> - 2013-10-10 20:26:14
Attachments:
dirichlet_nodal.patch
|
> That key point relates to the constraint equation algorithm, though... > but I guess that's the only hard part? > > I think that the first thing I'd upgrade for dirichlet nodes and edges > would be the API (very straightforward "add_foo(ForwardDeclaredFoo&)" > declarations); next the data structures (no modifications necessary if > we go the "use boundary ids corresponding to nodes and edges" route), > finally the algorithms (not too hard once the data structures are > done). > > No, scratch that. The very first thing I'd do is add "boundary ids > that apply to edges" support. > > As to the algorithm... cross your fingers, but I suspect that with the > current refactoring all you'd have to do is upgrade the > "do_this_side", "is_boundary_node[n]" and "is_boundary_edge[e]" > calculations in ConstrainDirichlet::apply_dirichlet_impl and you'll be > done. Well, that was easy! The attached patch works for me for adding nodal Dirichlet BCs. I'll look at adding support for edge Dirichlet BCs next. David |
From: David K. <dkn...@se...> - 2013-10-11 20:54:49
|
Hi Roy, I've got a branch node_and_edge_dirichlet in my fork on github (github.com/dknez/libmesh) which is working for me. The changes to ConstrainDirichlet were indeed simple. I also added some methods in BoundaryInfo to allow us to add edge boundary ids. I've tested this on a modified version of systems_of_equations_ex6 (also in the branch) and it works well. The branch is based on your adjoint_dirichlet branch, so I'll wait for you to merge that before I make a pull request. David > As to the algorithm... cross your fingers, but I suspect that with the > current refactoring all you'd have to do is upgrade the > "do_this_side", "is_boundary_node[n]" and "is_boundary_edge[e]" > calculations in ConstrainDirichlet::apply_dirichlet_impl and you'll be > done. |
From: David K. <dkn...@se...> - 2013-10-09 16:34:20
|
On 10/09/2013 10:26 AM, Roy Stogner wrote: > > On Tue, 8 Oct 2013, David Knezevic wrote: > >> However, I still get compilation errors with --enable-complex (on >> eb4d88f). Have you tested this? > > No; I just replaced the "complex won't implicitly convert to bool" > problem with an "int won't implicitly convert to complex" problem. > I'm replacing that with an explicit conversion and testing the > --enable-complex build now. OK. Let me know when it's ready. I can test an app that uses --enable-complex and DirichletBoundary. > >> DirichletBoundary on nodes. Do you have any suggestions on how I >> should get started? I think the key point from your original email >> was this: >> >> "For parallel consistency we actually do: >> 1. Interpolate at nodes >> 2. L2 project any edge degrees of freedom left over when holding node >> dofs fixed >> 3. L2 project any face dofs left over when holding node and edge dofs >> fixed " > > That key point relates to the constraint equation algorithm, though... > but I guess that's the only hard part? > > I think that the first thing I'd upgrade for dirichlet nodes and edges > would be the API (very straightforward "add_foo(ForwardDeclaredFoo&)" > declarations); next the data structures (no modifications necessary if > we go the "use boundary ids corresponding to nodes and edges" route), > finally the algorithms (not too hard once the data structures are > done). > > No, scratch that. The very first thing I'd do is add "boundary ids > that apply to edges" support. > > As to the algorithm... cross your fingers, but I suspect that with the > current refactoring all you'd have to do is upgrade the > "do_this_side", "is_boundary_node[n]" and "is_boundary_edge[e]" > calculations in ConstrainDirichlet::apply_dirichlet_impl and you'll be > done. OK, thanks! David |
From: Roy S. <roy...@ic...> - 2013-10-09 17:00:21
|
On Wed, 9 Oct 2013, David Knezevic wrote: > On 10/09/2013 10:26 AM, Roy Stogner wrote: >> >> No; I just replaced the "complex won't implicitly convert to bool" >> problem with an "int won't implicitly convert to complex" problem. >> I'm replacing that with an explicit conversion and testing the >> --enable-complex build now. > > OK. Let me know when it's ready. I can test an app that uses > --enable-complex and DirichletBoundary. It should be compiling (and it's passing simple examples for me) as of 0ebe32f2. --- Roy |
From: David K. <dkn...@se...> - 2013-10-09 18:41:51
|
On 10/09/2013 01:00 PM, Roy Stogner wrote: > > On Wed, 9 Oct 2013, David Knezevic wrote: > >> On 10/09/2013 10:26 AM, Roy Stogner wrote: >>> >>> No; I just replaced the "complex won't implicitly convert to bool" >>> problem with an "int won't implicitly convert to complex" problem. >>> I'm replacing that with an explicit conversion and testing the >>> --enable-complex build now. >> >> OK. Let me know when it's ready. I can test an app that uses >> --enable-complex and DirichletBoundary. > > It should be compiling (and it's passing simple examples for me) as of > 0ebe32f2. Works for me with --enable-complex too, thanks. David |