search

MASTmultiphysics / mast-multiphysics

Multidisciplinary-design Adaptation and Sensitivity Toolkit (MAST) - Sensitivity-enabled multiphysics FEA for design
https://www.mast-multiphysics.com
GNU Lesser General Public License v2.1
44 stars 24 forks source link

POINT_MOMENT about z-axis not applied #46

Closed JohnDN90 closed 4 years ago

JohnDN90 commented 4 years ago

I've been testing MAST::POINT_MOMENT to test a spring-like element I'm implementing that behaves like Nastran's CBUSH element. I have a single bushing element (with stiffness in all six DOFs) aligned on the x-axis and the left end (at the origin) is fixed. Applying a moment about the x-axis, M_x, at the right end matches Nastran's results. It works with a moment about the y-axis, M_y, at the right end also. However, when I try a moment about the z-axis, M_z, at the right end it results in zero displacements.

The initial residual is also zero. I was trying to track down the issue and made it down to here. vec on line 209 is what I expect it to be, but the M_z value gets set to zero by line 220. If I change the logic from dof_indices[i] >= last_dof to dof_indices[i] > last_dof, then the value is no longer zeroed out and I get the expected displacement.

So, is the >= a bug or is there something else going on that I need to dive deeper into?

manavbhatia commented 4 years ago

libMesh::DofMap::end_dof() returns the dof after all dofs on a processor. So, if the last dof on a processor is 21, then the end_dof() should be 22.

So, if we don't want the local processor to set values from 22 onwards, then we should maintain the >=.

However, this should happen when multiple processors are involved in the communicator. If this is the case, then the processor that owns the dofs should be setting the values there. Are you doing that?

JohnDN90 commented 4 years ago

I was running on a single processor, just calling the executable ./executable without explicitly calling MPI.

manavbhatia commented 4 years ago

In that case, could you please check how many dofs you have in the system and see what calls to last_dof and end_dof return. This chunk of the code still uses last_dof. Maybe this has a different behavior than end_dof.

JohnDN90 commented 4 years ago

Just checked it out, first_dof = 0, last_dof = 11, and end_dof = 12.

Edit: Oh, and there are 12 DOFs in my system (2 nodes, 6 DOFs each, DOF #s 0-11)

manavbhatia commented 4 years ago

Ok. So, if we retain the use of last_dof then we should change <= to <. However, this method in libmesh has been deprecated. So, I think the appropriate action will be to keep <= and use end_dof, instead of last_dof.