• From: Gothenburg, Sweden
  • Registered: 08-09-2009
  • Posts: 1,419

Re: tr_shell01 and NodalLoad

Hi
I checked the files, and I see you have you have the same nodal load in both cases. For the x and y files to give the same results the load must also be rotated (as you had done earlier, i think you must have just forgotten about it here).

As far as I can tell, the element does have an extra spurious zero eigenmode whenever it is had reduced integration. Depending on the analysis, this might not end up being a problem, but for very simple case of a plane, the spurious modes might appear. The element definitely needs reduced integration, because full integration will lead to locking.
Or there could just be another bug in the element.

  • Registered: 16-10-2010
  • Posts: 407

Re: tr_shell01 and NodalLoad

Yes, but my aim was not to obtain the same result, but to see bending. I've used reduced integration in each case. In attachment another file with the nodal load in Z direction (bending expected). Instead of bending, I get the deformed shape as shown in the pic in the zip file; in my opinion there's another bug.

Post's attachments

wallXYrot45yB.zip 26.48 kb, 5 downloads since 2014-11-27 

You don't have the permssions to download the attachments of this post.
  • From: Gothenburg, Sweden
  • Registered: 08-09-2009
  • Posts: 1,419

Re: tr_shell01 and NodalLoad

As I mentioned, with reduced integration the element has a spurious mode. There is no difference in behavior between wallXYrot45x and wallrot45y if you load them in the same way (in your wallXYrot45x.in file, the nodal load was along the x-axis, which only caused in plane deformation of the membrane part).

To me, the shape of the elements clearly indicate a spurious mode (the twisted shape of each element).
You have happened to prescribe boundary conditions which happen to allow for this zig-zag mode. If you where to change to boundary conditions, so say, prescribe all the nodes on a whole edge, then this mode cannot appear anymore.

We don't have any checks for spurious modes in OOFEM, so using reduced integration in some elements always comes with this risk.

The best solution would probably to be to implement the MITC4 type (from Bathe if I recall correctly), which do not exhibit neither locking or spurious modes. It should only require some extra computations of the B-matrix in the quad1mindlinshell3d element, and it should become a MITC4 element.

  • Registered: 16-10-2010
  • Posts: 407

Re: tr_shell01 and NodalLoad

Thanks for the explanation, now I focused where is the problem.
Removing the flag "reducedintegration" from the shell elements lines I get the expected result, because the spurious modes are cleaned out. However, extreme shear locking can occur.

Moreover, you said:

...that's Quad1MindlinShell3D. It requires underintegration to be any good though.

and, in  the post you reported previously (http://www.oofem.org/forum/viewtopic.ph … 48&p=2),

It's OK for thicker plates; Length/thickness ~ 10, but it is really really bad for Length/thickness ~100 (like in your example).

So, if I have a thickness of 85mm like in the examples, with an element size (originally, in the first examples) of 300x300mm, the shear locking can be a problem?

Finally, I've already used MITC4 in opensees; when I'll have some time I'll try to implement Bathe's shell in oofem starting from Quad1MindlinShell3D.

thanks

  • From: Gothenburg, Sweden
  • Registered: 08-09-2009
  • Posts: 1,419

Re: tr_shell01 and NodalLoad

Just as a first disclaimer:  The code for transformations and such are nontrivial, and there are plenty of room for possible bugs, but as far as I can tell, I only see expected results (though I have not compared to values with any external FE-solver)

As far as I know the element should be OK for thicker shells with no noticeable shear locking.

I would recommend adding a parameter to quad1mindlin as "integrationtype x",  where x is
1 = full
2 = reduced
3 = mixed tensorial

  • Registered: 16-10-2010
  • Posts: 407

Re: tr_shell01 and NodalLoad

Mikael, I think there is another error in quad1mindLinshell3d.c. In Quad1MindlinShell3D::computeLumpedMassMatrix (line 442) I corrected

answer.resize(12, 12);

into

answer.resize(24, 24);

Do you agree?

Maybe this error is other shell elements too? (I remember that you corrected also other shells)
An why there is no computeLumpedMassMatrix in tr_shell01.C?

thanks

  • From: Gothenburg, Sweden
  • Registered: 08-09-2009
  • Posts: 1,419

Re: tr_shell01 and NodalLoad

Yes, the size should be 24.
Far from everything is tested in most elements, and some missing or broken code is likely.


TR_SHELL01 overloads the "giveCharacteristicMatrix" for all types of matrices, including mass matrices, so it should work (unless some piece of code specifically calls "computeMassMatrix", in which case it would break).

  • Registered: 16-10-2010
  • Posts: 407

Re: tr_shell01 and NodalLoad

Hi Mikael,
I found the same error that happened for tr_shell01 elements also in beam3d:

Error: (floatarray.C:543)
In oofem::FloatArray::assemble:
dimensions of 'fe' (6) and 'loc' (0) mismatch

In attachment, a simple input file to reproduce the problem.

If needed I'll post also the stack trace.

Giovanni

Post's attachments

prova.in 960 b, 1 downloads since 2015-04-27 

You don't have the permssions to download the attachments of this post.
  • From: Gothenburg, Sweden
  • Registered: 08-09-2009
  • Posts: 1,419

Re: tr_shell01 and NodalLoad

Short version, do this:

NodalLoad 2 loadTimeFunction 1 Components 1 10.   DOFs 1  3   set 1

(the problem is unrelated to whatever elements you might use)

Long version:
When using boundary conditions on sets, the idea I had was to not rely on the implied dofs that might be created in nodes.

For example, one might have beam supports inside a solid, which means that some nodes will have rotational DOFs as well. Or there might be a contact anslysis (sometime in the future) where new DOFs are dynamically added to the node.

In those cases, we cannot rely on specifying a nodal load as just

NodalLoad 2 loadTimeFunction 1 Components 6 0 0 10 0 0 0 set 1

since we cannot know in advance what DOFs those actually refer to (you just happen to know that in this case, it's {D_u, D_v, D_w, R_u, R_v, R_w}).

Instead, even though it requires more typing, I believe that the (general) Neumann type boundary conditions should specify what DOFs the load applies to:

NodalLoad 2 loadTimeFunction 1 Components 6 0 0 10 0 0 0 set 1 DOFs 6 1 2 3 4 5 6

and you can even skip out on the components you know what you do not care about

NodalLoad 2 loadTimeFunction 1 Components 1 10.   DOFs 1  3   set 1

or, if one wants

# Apply the force = [5, 3, 5]
NodalLoad 2 loadTimeFunction 1 Components 3 5. 3. 5.   DOFs 3  1 2 3   set 1

This is the same as what's done for dirichler boundary conditions (if you use sets).


There is no warning that you are missing the DOFs input for the nodal load, because it needs to remain backwards compatible (for now).

  • Registered: 16-10-2010
  • Posts: 407

Re: tr_shell01 and NodalLoad

thank you Mikael, very clear. I agree with you, this is the best approach to the problem.