Topic: solid, shells and beams in the same model

Hi all,
in some (rare) cases, one would insert in the same model solids, shells and beams. In the subsequent example, I have one shell, one beam and one Lspace element in the same model. OOFEM blocks at "Consistency check              failed" and no output is given.

The problem is of course the solid elements, which has no rotational dofs. I remove temporarely the consistency check; which are the major drawbacks of doing this?
In particular, it is not clear what "Node :: checkConsistency()" exactly does on master/slave nodes.

elemMix.out
-> mixing elements
LinearStatic nsteps 1
domain 3dShell
OutputManager tstep_all dofman_all element_all
ndofman 14 nelem 17 ncrosssect 3 nmat 1 nbc 19 nic 0 nltf 2 nset 19
node 1 coords 3 0 0 0 
node 2 coords 3 0 0 3 
node 3 coords 3 1 0 0 
node 4 coords 3 2 0 0 
node 5 coords 3 1 0 1 
node 6 coords 3 2 0 1 
node 7 coords 3 3 0 0 
node 8 coords 3 4 0 0 
node 9 coords 3 4 0 1 
node 10 coords 3 3 0 1 
node 11 coords 3 3 1 0 
node 12 coords 3 4 1 0 
node 13 coords 3 4 1 1 
node 14 coords 3 3 1 1 
Beam3d 1 nodes 2 1 2 mat 1 crossSect 2 refAngle 0 boundaryLoads 2 7 1 
mitc4shell 2 nodes 4 3 4 6 5  crossSect 3 mat 1  lcs1 3 1 0 0 
LSpace 4 nodes 8 11 12 13 14 7 8 9 10 mat 1 crossSect 1
lumpedmass 5 nodes 1 3 crosssect 1 components 6 0.500764489173889 0.500764489173889 0 0 0 0
lumpedmass 6 nodes 1 4 crosssect 1 components 6 0.500764489173889 0.500764489173889 0 0 0 0
lumpedmass 7 nodes 1 6 crosssect 1 components 6 0.500764489173889 0.500764489173889 0 0 0 0
lumpedmass 8 nodes 1 5 crosssect 1 components 6 0.500764489173889 0.500764489173889 0 0 0 0
lumpedmass 9 nodes 1 11 crosssect 1 components 6 1.00152897834778 1.00152897834778 0 0 0 0
lumpedmass 10 nodes 1 12 crosssect 1 components 6 1.00152897834778 1.00152897834778 0 0 0 0
lumpedmass 11 nodes 1 13 crosssect 1 components 6 1.00152897834778 1.00152897834778 0 0 0 0
lumpedmass 12 nodes 1 14 crosssect 1 components 6 1.00152897834778 1.00152897834778 0 0 0 0
lumpedmass 13 nodes 1 7 crosssect 1 components 6 1.00152897834778 1.00152897834778 0 0 0 0
lumpedmass 14 nodes 1 8 crosssect 1 components 6 1.00152897834778 1.00152897834778 0 0 0 0
lumpedmass 15 nodes 1 9 crosssect 1 components 6 1.00152897834778 1.00152897834778 0 0 0 0
lumpedmass 16 nodes 1 10 crosssect 1 components 6 1.00152897834778 1.00152897834778 0 0 0 0
lumpedmass 17 nodes 1 1 crosssect 1 components 6 0.00222339434549212 0.00222339434549212 0 0 0 0
lumpedmass 18 nodes 1 2 crosssect 1 components 6 0.00222339434549212 0.00222339434549212 0 0 0 0
# fictitious section for LumpedMass elements
SimpleCS 1 thick 0 drillstiffness 0
SimpleCS 2 area 0.000184999997145496 Iy 1.02476951369113E-08 Iz 1.02476951369113E-08 Ik 9.81333458938138E-10 shearareay 8.3999999333173E-05 shearareaz 8.33333397167735E-05 thick 0.025000000372529 width 0.025000000372529
SimpleCS 3 thick 0.25 drillstiffness 1.e8
IsoLE 1 d 0 E 209999984 n 0.3 tAlpha 1.20000004244503E-05
BoundaryCondition 1 loadTimeFunction 1 DOFs 6 1 2 3 4 5 6  values 6 0 0 0 0 0 0  set 1
BoundaryCondition 2 loadTimeFunction 1 DOFs 6 1 2 3 4 5 6  values 6 0 0 0 0 0 0  set 2
BoundaryCondition 3 loadTimeFunction 1 DOFs 6 1 2 3 4 5 6  values 6 0 0 0 0 0 0  set 3
BoundaryCondition 4 loadTimeFunction 1 DOFs 6 1 2 3 4 5 6  values 6 0 0 0 0 0 0  set 4
BoundaryCondition 5 loadTimeFunction 1 DOFs 6 1 2 3 4 5 6  values 6 0 0 0 0 0 0  set 5
BoundaryCondition 6 loadTimeFunction 1 DOFs 6 1 2 3 4 5 6  values 6 0 0 0 0 0 0  set 6
ConstantEdgeLoad 7 loadTimeFunction 2  csType 0 Components 1 -0.0145409991964698 DOFs 1 3
NodalLoad 8 loadTimeFunction 2 Components 1 -4.91249990463257 DOFs 1 3 set 8
NodalLoad 9 loadTimeFunction 2 Components 1 -4.91249990463257 DOFs 1 3 set 9
NodalLoad 10 loadTimeFunction 2 Components 1 -4.91249990463257 DOFs 1 3 set 10
NodalLoad 11 loadTimeFunction 2 Components 1 -4.91249990463257 DOFs 1 3 set 11
NodalLoad 12 loadTimeFunction 2 Components 1 -9.82499980926514 DOFs 1 3 set 12
NodalLoad 13 loadTimeFunction 2 Components 1 -9.82499980926514 DOFs 1 3 set 13
NodalLoad 14 loadTimeFunction 2 Components 1 -9.82499980926514 DOFs 1 3 set 14
NodalLoad 15 loadTimeFunction 2 Components 1 -9.82499980926514 DOFs 1 3 set 15
NodalLoad 16 loadTimeFunction 2 Components 1 -9.82499980926514 DOFs 1 3 set 16
NodalLoad 17 loadTimeFunction 2 Components 1 -9.82499980926514 DOFs 1 3 set 17
NodalLoad 18 loadTimeFunction 2 Components 1 -9.82499980926514 DOFs 1 3 set 18
NodalLoad 19 loadTimeFunction 2 Components 1 -9.82499980926514 DOFs 1 3 set 19
ConstantFunction 1 f(t) 1.0
PiecewiseLinFunction 2 npoints 2 t 2 0.0 1 f(t) 2 0.0 1.0
set 1 nodes 1 1
set 2 nodes 1 3
set 3 nodes 1 4
set 4 nodes 1 7
set 5 nodes 1 8
set 6 nodes 1 11
set 8 nodes 1 3
set 9 nodes 1 4
set 10 nodes 1 6
set 11 nodes 1 5
set 12 nodes 1 11
set 13 nodes 1 12
set 14 nodes 1 13
set 15 nodes 1 14
set 16 nodes 1 7
set 17 nodes 1 8
set 18 nodes 1 9
set 19 nodes 1 10
set 7 elementedges 2 1 1

2

Re: solid, shells and beams in the same model

Hi,
it seems to me that the problem is in applying lumpedmass elements to nodes with different number of DOFs. For example, in your test file, node 11 is connected to LSPACE element, so it will get 3 displacement DOFS assigned. On the other hand, the lumpedmass element is connected to node 11 as well, declaring 6 DOFs (6 lumped mass values). This leads to complains and I believe they are valid, as the solver does not know which lumped mass components to add to node DOFs.

Side note: Perhaps, he part of the problem is in fact, that lumpedmass element does not know about the physical meaning of its DOFs (this allows to use it in general situations). And even if it will, then in such node you will get 6 DOFS allocated, but only 3 displacement DOFs will receive stiffness contribution, so they have to be restrained.

Re: solid, shells and beams in the same model

I think we should require lumpedmass to be explicit about the dofs:

lumpedmass 17 nodes 1 1 crosssect 1 dofidmask 2 1 2 components 2 0.00222339434549212 0.00222339434549212

instead of relying on the dofs (and the order of the dofs stored in the dofmanager).

In fact.. we have std::map of dofs stored in the dofmanager, so the order isn't even well defined necessarily?! I think this is a huge bug currently in the code. I think asking lumped "mass" to specify the dofs will allow it to be used generally for all types of "inertia" terms.