Hi all.
I'm modeling a problem where a body is pulled on a small patch of the boundary by a tool. The movement of the tool is prescribed. So I thought I'd use a boundary condition defined by a function, as so:
def table_select_by_ts(ts, coords, bc=None, problem=None, table=None): return np.tile(table[ts.step], (coords.shape[0], 1))
tool_disp_fun = Function('tool_disp_fun', table_select_by_ts, extra_args={'table': displacement_table}) tool_velo_fun = Function('tool_velo_fun', table_select_by_ts, extra_args={'table': velocity_table}) tool_accel_fun = Function('tool_accel_fun', table_select_by_ts, extra_args={'table': accel_table})
tool_bc = EssentialBC('tool_bc', self._tool, { 'u.all': tool_disp_fun, 'v.all': tool_velo_fun, 'a.all': tool_accel_fun })
Then I tried to use it with the Newmark solver, but got a behaviour where the solver doesn't responde to changes in direction. It produces a nice result for a constant-velocity movement in one direction, but fails if there is then a bend in the path. As much as I understand, this is because the solver's idea is to always combine the previous acceleration ield with the current, and so it misses the prescribed acceleration when it changes.
I also looked at Generalized-alpha and Bathe, but those seem to only use the first boundary condition and not update on subsequent frames.
So my question is, what do you think the right solver for this problem is, or am I using the right solver already but doing it wrong?
Thanks, Yosef Meller.
Hi Yosef,
On 3/21/23 13:15, Yosef Meller wrote:
Hi all.
I'm modeling a problem where a body is pulled on a small patch of the boundary by a tool. The movement of the tool is prescribed. So I thought I'd use a boundary condition defined by a function, as so:
def table_select_by_ts(ts, coords, bc=None, problem=None, table=None): return np.tile(table[ts.step], (coords.shape[0], 1))
tool_disp_fun = Function('tool_disp_fun', table_select_by_ts, extra_args={'table': displacement_table}) tool_velo_fun = Function('tool_velo_fun', table_select_by_ts, extra_args={'table': velocity_table}) tool_accel_fun = Function('tool_accel_fun', table_select_by_ts, extra_args={'table': accel_table})
tool_bc = EssentialBC('tool_bc', self._tool, { 'u.all': tool_disp_fun, 'v.all': tool_velo_fun, 'a.all': tool_accel_fun })
The code above seems OK.
What do you mean by "movement of the tool"? Is it like in [1], where vertices
in a fixed boundary region move, or is the tool moving over the mesh so that
the self._tool region contents changes? The latter would be more difficult,
it is not well supported besides [2].
[1] http://sfepy.org/doc-devel/examples/linear_elasticity-seismic_load.html#line... [2] http://sfepy.org/doc-devel/examples/diffusion-laplace_time_ebcs.html
Then I tried to use it with the Newmark solver, but got a behaviour where the solver doesn't responde to changes in direction. It produces a nice result for a constant-velocity movement in one direction, but fails if there is then a bend in the path. As much as I understand, this is because the solver's idea is to always combine the previous acceleration ield with the current, and so it misses the prescribed acceleration when it changes.
I also looked at Generalized-alpha and Bathe, but those seem to only use the first boundary condition and not update on subsequent frames.
So my question is, what do you think the right solver for this problem is, or am I using the right solver already but doing it wrong?
The solvers you mention are for elastodynamical problems, so, based on your description, they seem to be the correct choice. Do you care for the dynamical/inertial effects, right?
You can post a small-size self-contained example if you want. I cannot say more without seeing the actual problem.
Best regards, r.
Thanks for responding.
On Tue, Mar 21, 2023 at 11:28 PM Robert Cimrman <cimrman3@ntc.zcu.cz> wrote:
On 3/21/23 13:15, Yosef Meller wrote:
What do you mean by "movement of the tool"? Is it like in [1], where vertices in a fixed boundary region move, or is the tool moving over the mesh so that the
self._toolregion contents changes? The latter would be more difficult, it is not well supported besides [2].
The first option. I hope the attached inimal example makes it clearer.
You can post a small-size self-contained example if you want. I cannot say more without seeing the actual problem.
I'm attaching the nost minimal reproduction I could make. If you look at the last generated frame in sfepy-view, you'll see that the displacement at the tool region (top) is going up, as if continuing the movement from the first frames, although disp.dat prescribes a sideways movement.
Thanks for any idea, Yosef.
On 3/22/23 08:13, Yosef Meller wrote:
Thanks for responding.
On Tue, Mar 21, 2023 at 11:28 PM Robert Cimrman <cimrman3@ntc.zcu.cz> wrote:
On 3/21/23 13:15, Yosef Meller wrote:
What do you mean by "movement of the tool"? Is it like in [1], where vertices in a fixed boundary region move, or is the tool moving over the mesh so that the
self._toolregion contents changes? The latter would be more difficult, it is not well supported besides [2].The first option. I hope the attached inimal example makes it clearer.
You can post a small-size self-contained example if you want. I cannot say more without seeing the actual problem.
I'm attaching the nost minimal reproduction I could make. If you look at the last generated frame in sfepy-view, you'll see that the displacement at the tool region (top) is going up, as if continuing the movement from the first frames, although disp.dat prescribes a sideways movement.
I used the current git version of sfepy and it looks OK for me, I checked with:
sfepy-view dmn.*.vtk -f u:wu:f100:p0 1:vw:p0
By pressing PageUp, PageDown keys I can see the lateral movement after the initial elongation. Rotate the mesh a bit, as the lateral movement is parallel to the default view direction.
r.
On Wed, Mar 22, 2023 at 12:31 PM Robert Cimrman <cimrman3@ntc.zcu.cz> wrote:
I'm attaching the nost minimal reproduction I could make. If you look at the last generated frame in sfepy-view, you'll see that the displacement at the tool region (top) is going up, as if continuing the movement from the first frames, although disp.dat prescribes a sideways movement.
I used the current git version of sfepy and it looks OK for me, I checked with:
Indeed, the most recent git version is key. I was working with a previous commit. After git bisection, I isolated the change to merging PR #953, the seismic load work. So this seems to have fixed something that was broken before.
On 3/22/23 13:02, Yosef Meller wrote:
On Wed, Mar 22, 2023 at 12:31 PM Robert Cimrman <cimrman3@ntc.zcu.cz> wrote:
I'm attaching the nost minimal reproduction I could make. If you look at the last generated frame in sfepy-view, you'll see that the displacement at the tool region (top) is going up, as if continuing the movement from the first frames, although disp.dat prescribes a sideways movement.
I used the current git version of sfepy and it looks OK for me, I checked with:
Indeed, the most recent git version is key. I was working with a previous commit. After git bisection, I isolated the change to merging PR #953, the seismic load work. So this seems to have fixed something that was broken before.
Yes, the seismic load example was added after fixing a bug in application of the EBCs. I somehow assumed you were using the git version :)
r.
On 3/22/23 13:12, Robert Cimrman wrote:
On 3/22/23 13:02, Yosef Meller wrote:
On Wed, Mar 22, 2023 at 12:31 PM Robert Cimrman <cimrman3@ntc.zcu.cz> wrote:
I'm attaching the nost minimal reproduction I could make. If you look at the last generated frame in sfepy-view, you'll see that the displacement at the tool region (top) is going up, as if continuing the movement from the first frames, although disp.dat prescribes a sideways movement.
I used the current git version of sfepy and it looks OK for me, I checked with:
Indeed, the most recent git version is key. I was working with a previous commit. After git bisection, I isolated the change to merging PR #953, the seismic load work. So this seems to have fixed something that was broken before.
Yes, the seismic load example was added after fixing a bug in application of the EBCs. I somehow assumed you were using the git version :)
There are still some problems to solve, see #972.
r.
participants (2)
-
Robert Cimrman -
Yosef Meller