Understanding surface region DOFs and function EBCs
Hi All.
I'm trying to assign boundary conditions to a surface region on my mesh using a function. The surface is juat six facets arranged in a fan, so defined by seven vertices. When printing the region, I get the description copied below. Looks like the definition is correct. So I expect there to be 7 DOFs for the function to set. This is further reinforced by H1NodalMixin.set_dofs() , which calls unique(self.get_dofs_in_region(region)), and expects the result to be vertex ids.
However, set_dofs() fails because the number of BC values returned from my function is 7, instead of 19. checking within self.get_dofs_in_region(region) I see that I get 7 vdofs (vertices) + 12 edge dofs, which have numbers higher than the number of vertices, contrary to the apparent expectation of set_dof() that all numbers denote coordinates.
I checke that my mesh is built ok, but since the region is defined by vertices, that shouldn't be it anyway. So there is something I don't understand here. Why are edge dofs returned and treated as coordinate numbers, which they are not? What can I do to check how this happened?
Thanks, Yosef.
Region:grasp_prims can: list: [True, True, True, False] can_cells: False can_edges: True can_faces: True can_vertices: True cmesh: CMesh: n_coor: 4655, dim 3, tdim: 3, n_el 15451 definition: vertex 2424,2434,2435,2437,2438,2601,2602 dim: 3 domain: FEDomain:soft_body entities: list: [array([2424, 2434, 2435, 2437, 2438, 2601, 2602], dtype=uint32), array([ 435, 2564, 3248, 3358, 3392, 3393, 3394, 3395, 3452, 3504, 3512, 3513], dtype=uint32), array([3082, 3083, 3150, 3160, 3244, 3245], dtype=uint32), array([], dtype=uint32)] extra_options: None is_empty: False kind: facet kind_tdim: 2 mirror_maps: dict with keys: [] mirror_regions: dict with keys: [] n_v_max: 4655 name: grasp_prims parent: None parse_def: E_VI<vertex 2424 2434 2435 2437 2438 2601 2602> shape: Struct tdim: 3 true_kind: face
Hi Yosef,
On 4/24/23 14:13, Yosef Meller wrote:
Hi All.
I'm trying to assign boundary conditions to a surface region on my mesh using a function. The surface is juat six facets arranged in a fan, so defined by seven vertices. When printing the region, I get the description copied below. Looks like the definition is correct. So I expect there to be 7 DOFs for the function to set. This is further reinforced by H1NodalMixin.set_dofs(), which calls unique(self.get_dofs_in_region(region)), and expects the result to be vertex ids.
Not just vertex ids, but ids of all the dofs (the higher order ones too). There are some naming inconsistencies from the past, and some field kinds do not support that, but it should work that way.
However, set_dofs() fails because the number of BC values returned from my function is 7, instead of 19. checking within self.get_dofs_in_region(region) I see that I get 7 vdofs (vertices) + 12 edge dofs, which have numbers higher than the number of vertices, contrary to the apparent expectation of set_dof() that all numbers denote coordinates.
I checke that my mesh is built ok, but since the region is defined by vertices, that shouldn't be it anyway. So there is something I don't understand here. Why are edge dofs returned and treated as coordinate numbers, which they are not? What can I do to check how this happened?
For the default nodal basis, the edge dof coordinates are well defined as the coordinates along each edge. Your BC evaluation function should receive 19 coordinates and return 19 values, is that so?
r.
My function indeed receives 19 coordinates, but I don't understand which ones were picked. Do you mean by "higher order" that the extra (edge) dofs are given coordinates that are not actual mesh vertices? How are those created? I guess this is probably me not understanding the internals of FEM.
On Mon, Apr 24, 2023 at 3:46 PM Robert Cimrman <cimrman3@ntc.zcu.cz> wrote:
Hi Yosef,
On 4/24/23 14:13, Yosef Meller wrote:
Hi All.
I'm trying to assign boundary conditions to a surface region on my mesh using a function. The surface is juat six facets arranged in a fan, so defined by seven vertices. When printing the region, I get the description copied below. Looks like the definition is correct. So I expect there to be 7 DOFs for the function to set. This is further reinforced by H1NodalMixin.set_dofs(), which calls unique(self.get_dofs_in_region(region)), and expects the result to be vertex ids.
Not just vertex ids, but ids of all the dofs (the higher order ones too). There are some naming inconsistencies from the past, and some field kinds do not support that, but it should work that way.
However, set_dofs() fails because the number of BC values returned from my function is 7, instead of 19. checking within self.get_dofs_in_region(region) I see that I get 7 vdofs (vertices) + 12 edge dofs, which have numbers higher than the number of vertices, contrary to the apparent expectation of set_dof() that all numbers denote coordinates.
I checke that my mesh is built ok, but since the region is defined by vertices, that shouldn't be it anyway. So there is something I don't understand here. Why are edge dofs returned and treated as coordinate numbers, which they are not? What can I do to check how this happened?
For the default nodal basis, the edge dof coordinates are well defined as the coordinates along each edge. Your BC evaluation function should receive 19 coordinates and return 19 values, is that so?
r.
SfePy mailing list -- sfepy@python.org To unsubscribe send an email to sfepy-leave@python.org https://mail.python.org/mailman3/lists/sfepy.python.org/ Member address: yosefm@gmail.com
On 4/24/23 14:49, Yosef Meller wrote:
My function indeed receives 19 coordinates, but I don't understand which ones were picked. Do you mean by "higher order" that the extra (edge) dofs are given coordinates that are not actual mesh vertices? How are those created? I guess this is probably me not understanding the internals of FEM.
In your case those extra coordinates are the centers of the edges in the region. Anyway, the BC function should return a value for each coordinate it receives, disregarding their origin. The fact that some coordinates correspond to mesh vertices is a detail related to the nodal finite element basis. For other bases, the coordinates can be for example quadrature points. There are FE bases (also in sfepy) where the degrees of freedom are not the interpolated function values in the FE nodes coordinates.
What kind of function do you have? If you only have values tabulated in mesh vertices, you would need doing some interpolation.
r.
On Mon, Apr 24, 2023 at 3:46 PM Robert Cimrman <cimrman3@ntc.zcu.cz> wrote:
Hi Yosef,
On 4/24/23 14:13, Yosef Meller wrote:
Hi All.
I'm trying to assign boundary conditions to a surface region on my mesh using a function. The surface is juat six facets arranged in a fan, so defined by seven vertices. When printing the region, I get the description copied below. Looks like the definition is correct. So I expect there to be 7 DOFs for the function to set. This is further reinforced by H1NodalMixin.set_dofs(), which calls unique(self.get_dofs_in_region(region)), and expects the result to be vertex ids.
Not just vertex ids, but ids of all the dofs (the higher order ones too). There are some naming inconsistencies from the past, and some field kinds do not support that, but it should work that way.
However, set_dofs() fails because the number of BC values returned from my function is 7, instead of 19. checking within self.get_dofs_in_region(region) I see that I get 7 vdofs (vertices) + 12 edge dofs, which have numbers higher than the number of vertices, contrary to the apparent expectation of set_dof() that all numbers denote coordinates.
I checke that my mesh is built ok, but since the region is defined by vertices, that shouldn't be it anyway. So there is something I don't understand here. Why are edge dofs returned and treated as coordinate numbers, which they are not? What can I do to check how this happened?
For the default nodal basis, the edge dof coordinates are well defined as the coordinates along each edge. Your BC evaluation function should receive 19 coordinates and return 19 values, is that so?
r.
SfePy mailing list -- sfepy@python.org To unsubscribe send an email to sfepy-leave@python.org https://mail.python.org/mailman3/lists/sfepy.python.org/ Member address: yosefm@gmail.com
Quadrature points, I guess this seems obvious in hindsight :)
My function can calculate things on the fly, I just expected it would be faster by tabulating the values in advance, since I know all about the moving boundary. I'll just drop that optimization. I guess I can still do it if I take my knowledge of the integration order into account, but the saved performance isn't worth the shaky software engineering that would result from all that implicit knowledge in the tabulation phase.
Thanks, I have my way forward now.
On Mon, Apr 24, 2023 at 4:38 PM Robert Cimrman <cimrman3@ntc.zcu.cz> wrote:
My function indeed receives 19 coordinates, but I don't understand which ones were picked. Do you mean by "higher order" that the extra (edge) dofs are given coordinates that are not actual mesh vertices? How are
On 4/24/23 14:49, Yosef Meller wrote: those
created? I guess this is probably me not understanding the internals of FEM.
In your case those extra coordinates are the centers of the edges in the region. Anyway, the BC function should return a value for each coordinate it receives, disregarding their origin. The fact that some coordinates correspond to mesh vertices is a detail related to the nodal finite element basis. For other bases, the coordinates can be for example quadrature points. There are FE bases (also in sfepy) where the degrees of freedom are not the interpolated function values in the FE nodes coordinates.
What kind of function do you have? If you only have values tabulated in mesh vertices, you would need doing some interpolation.
r.
On Mon, Apr 24, 2023 at 3:46 PM Robert Cimrman <cimrman3@ntc.zcu.cz> wrote:
Hi Yosef,
On 4/24/23 14:13, Yosef Meller wrote:
Hi All.
I'm trying to assign boundary conditions to a surface region on my mesh using a function. The surface is juat six facets arranged in a fan, so defined by seven vertices. When printing the region, I get the description copied below. Looks like the definition is correct. So I expect there to be 7 DOFs for the function to set. This is further reinforced by H1NodalMixin.set_dofs(), which calls unique(self.get_dofs_in_region(region)), and expects the result to be vertex ids.
Not just vertex ids, but ids of all the dofs (the higher order ones too). There are some naming inconsistencies from the past, and some field kinds do not support that, but it should work that way.
However, set_dofs() fails because the number of BC values returned from my function is 7, instead of 19. checking within self.get_dofs_in_region(region) I see that I get 7 vdofs (vertices) + 12 edge dofs, which have numbers higher than the number of vertices, contrary to the apparent expectation of set_dof() that all numbers denote coordinates.
I checke that my mesh is built ok, but since the region is defined by vertices, that shouldn't be it anyway. So there is something I don't understand here. Why are edge dofs returned and treated as coordinate numbers, which they are not? What can I do to check how this happened?
For the default nodal basis, the edge dof coordinates are well defined as the coordinates along each edge. Your BC evaluation function should receive 19 coordinates and return 19 values, is that so?
r.
SfePy mailing list -- sfepy@python.org To unsubscribe send an email to sfepy-leave@python.org https://mail.python.org/mailman3/lists/sfepy.python.org/ Member address: yosefm@gmail.com
participants (2)
-
Robert Cimrman -
Yosef Meller