Allowed DOFs in feap 8.4

[R2197]

Hi all

I was working with 8 dof for quite some time and the program works perfectly. Now, I am trying to add more dofs, ideally 9 more but can manage if is a few less. But I see that when I add 17, the program crashes. I tried going step by step (9,10,11...) and saw that it runs till 13 and when I put 14 dofs, the program crashes.
What could be the reason for this? What is the maximum number of dofs that one can simulate?

Thanks in advance

[FEAP_Admin]

The problem is perhaps with the data input.  In the input files you have to wrap the input lines if there are more than 16 items to be read on an input line.
This will be an issue when specifying boundary conditions.  For example suppose that on the plane x = 0 you wish to constrain all the degrees of freedom, then you would need to use

Code: [Select]

EBOUndary
1 0  1 1 1 1 1 1 1 1 1 1 1 1 1 1
1
if you have 15 dofs.  The 15th dof needs to be on the second line since the first line has 2+14=16 entries on it and then 15th dof condition will not fit.

[FEAP_Admin]

PS:  Version 8.4 is very old.  You should consider upgrading to the current release.

[R2197]

Thanks for your reply. Yes, upgrading is something that is on my mind for a while now.

But apart from that, I already saw someone else's question about the DOFs and the line wrapping and have done it in my code as well. One of the things that I found in the 'M' file is that for 14 and higher DOFs, the line corresponding to the material writes wierdly. For eg. I am using elment 33 and 34, where 33 works perfectly and I use the same definitions for 34 just with the difference of element number.

mate 1
 user,33
  33,0,0,nt,0,3
  mu,lm,2222.0,nI,K1    !muhI,lambdahI,rhohIRt0,nhIt0,KhIt0I

and

mate 1
 user,34
  34,0,0,nt,0,3
  mu,lm,2222.0,nI,K1    !muhI,lambdahI,rhohIRt0,nhIt0,KhIt0I
 
And the resulting M files write

MATErial       1
 user  33   0   0   0   0   0   0   0   0   0
    33,0,0,nt,0,3
    mu,lm,2222.0,nI,K1
and

    34,0,0,nt,0,3
MATErial       1
 user  34  34   0   0   1   0   3   0   0   0   0   0   0   0   0
   0   0   0   0
    mu,lm,2222.0,nI,K1

and also the output files as shown in the images.


Could you comment on this?

Thanks

[Prof. R.L. Taylor]

It is not clear what is happening but the input is not correct.   The record with "user" includes a list of what does are assigned for the element, by default is it just 1 to ndf in sequence -- but you do need a second record if you have more than 13 dofs/node.

[Prof. R.L. Taylor]

One should note also that the form of the input for this record changed after ver8.4 -- be sure to check user manual for exact formats.

[Prof. S. Govindjee]

In FEAP version 8.4, you can follow what is happening in program/pmatin.f.

Line 120 calls tinput on your user,34 line, reading two strings and up to 14 numbers for possible dof reordering; if the numbers are not there then they default to zero.  Then line 137 will convert the second string to a number since the first string is 'user'.  It stores this value in uelnum and then casts it to the nearest integer and stores it in iel. This is your element number 34.  Starting at line 164 FEAP will try to deal with possible dof reorderings when the number of dofs exceeds 12 (so 13 or more).  For this purpose it will read additional lines in case the user wants dof reordering.

Thus if you were to have say 16 dofs your material cards should look like, if you are not performing any reordering of the dofs:

Code: [Select]

mate,1
  user 34 1 1 2 3 4 5 6 7 8 9 10 11 12
13 14 15 16
34,0,0,nt,0,3
mu,lm,2222.0,nI,K1
I recommend using the dof numbers instead of zeros or blanks to make sure you do not forget something (FEAP internally will convert zeros to the corresponding dof, see line 186).
You could get away with

Code: [Select]

mate,1
  user 34

34,0,0,nt,0,3
mu,lm,2222.0,nI,K1
The missing entries after 34 will default to 0 and the blank line will default to reading an additional 16 zeros.  All the zeros will get converted by FEAP to sequential values.  This is a bit unclear so listing the numbers as in my first suggestion is a better idea when dealing with high dof elements.

Note also that there is also the possibility of declaring the element-set to be different than the material number, 1 in your case.  This comes implicitly right after the 34 and before any dof reordering list.

For users of version 8.6.  This works nearly the same but some coding issues have been fixed up.  In particular, the USER line is specified as

Code: [Select]

MATErial,material_number
USER, user_element_number, element_set_number, dof_reordering_list(1:13)
dof_reordering_list(14:29)
etc.
If the element_set_number is omitted it will default to the number after MATErial.  If the reorder lists are omitted they default to sequential order.

[R2197]

Thank you Prof. Taylor and Prof. Govindjee

I have made the changes and the DOFs are now working. However, the code stops after the boundary conditions. The error message at the end of output files says ' *ERROR* ENDCLR: End of file encountered in TINPUT
         Unit Number =  12'. Here are my log, input and output files and a screenshot of the terminal window. Could you please have a look at it?

[Prof. S. Govindjee]

The problem is with the EBOUndary condition.  When FEAP sees EBOU it saves off the data and then processes it after the mesh is complete.  The process of saving/re-reading is not handling the extra dofs correctly.  The problem is fixed in the version 8.6.

Here is one quick thing you can try to see if it fixes the problem in 8.4.

In program/plinka.f find (near line 103, a few lines after statement label 40)

Code: [Select]

        close(iop)
Then just before this line add the following line

Code: [Select]

        write(iop,'(a)') ' ' ! Extra blank line for ndf > 13
This should resolve the TINPUT error on unit 12.  I am not sure if there are other problems you will run into -- upgrading is again recommended.

[R2197]

Thanks a lot Prof. Govindjee

It works now. Another quick question, so more DOFs mean more constants as well. I plan to input around 75. Will that also be an issue or the pointer d(*) manages it?

Thank you

[Prof. S. Govindjee]

In version 8.4 the default is d(300).  In version 8.6 it is d(350).

You can always increase the dimension via the input file, for example to increase the size to 400:

Code: [Select]

feap * * Cylinder
  ndf = 3
  ndm = 3
  nen = 8
  npd = 400
Alternately

Code: [Select]

feap * * Cylinder
  0 0 0 3 3 8 0 400
(note the stealth zero which is a parameter for controlling extra row/cols in the stiffness matrix)

[Prof. S. Govindjee]

I created a wiki page that gives a bit more information on specifying problem control values.  See http://feap.berkeley.edu/wiki/index.php?title=Control_values