Redundant indices related to nen/nst

[casebolt]

Hello,
I am working on implementing a particle based element, where the nodes used for the assembly of the local mass and stiffness matrices may exceed the number of nodes that actually exists within/on an element. Currently I have been combing through the code and manual and want to confirm some suspicions related to indices.

For the mapping of the local to global nodes, is the nst determined entity such that nst = nen*ndf? (where nen can be specified to be greater than the actual maximum number of element nodes upon the initiation of the problem.)

If this is true, does FEAP already have a process for skipping over redundant indices during assembly? For instance, lets say a 4-node element actually has 6 nodes whose stiffness is affected by element region, if the user specifies nen to be 6 or greater at the onset of the problem, will the program map the contributions to the 6 nodes or just the 4-element nodes? (assuming ix, xl, etc. are all properly setup for the 6 nodes)

[Prof. S. Govindjee]

NEN is set to the maximum number of nodes on any element in the mesh.  If given elements have fewer nodes that is fine.

Note also that one can remap element assumed orderings of dofs to other orderings using the material cards. 

Code: [Select]

MATErial ma
  etype uel eset g1 g2 g3 ... gndf
For a user elment etype = USER, uel = the user element number, eset = ma unless you are doing clever things, and g1...gndf are the  remapping you want.  By default gi = i.  See chapter 5 of the programmer manual.

To tell FEAP to completely mask off certain dofs in an element you can use the feature of setting up IX( ) under isw.eq.1.  See section 5.4.1 in the programmer's manual.

[FEAP_Admin]

See also Appendix A, the MATErial page, which gives an example of setting reordering and masking of dofs in elements from the input file.

[casebolt]

Hello,
Thank you for the input as it has helped quite a bit. I still have some minor questions regarding quantities such as nel and nen when it comes to amending ix.
Circling back to particle methods as a hypothetical, if I were using 4-node elements as an integration cells for more then just those 4-nodes, and amend the ix array to include additional addresses for a given element using either an umeshnn.f routine or in the element at isw.eq.1. Would I expect nel to automatically update regardless of the original construction? (I suspect it will as blkgen.f calculates it based off of the non zero integers within ix. I just want to confirm the order of operations as I am not sure if nel is stored at the creation the mesh or checked every time.)

Also I wanted to confirm whether I utilize undesignated indices in the material parameter array? For instance d(6). Just want to confirm whether this would break something or if I can assign a value to this index.

Thank you!

[Prof. S. Govindjee]

Ammending the IX array is a pretty special thing.  You have to observe two things:

  (1) Under isw.eq.1, IX( ) is NOT the element connectivity etc. from Table 3.4 in the programmer's manual -- under isw.eq.1 it is just used as a memory slot for passing some particular data [This is not the best of all programming styles but reflects FEAP decades long development cycle.] 

  (2) Under isw.eq.1 IX( ) is used to allow you (optionally) to turn nodes/dofs on and off.  You do this either by setting IX(1:ndf, 1) equal to 0 (off) or 1 (on), or by setting IX(1:ndf, 2:(nen+1)) to 0 or 1.  You can not add nodes to the elements, which is what I think you are try to say in your message.  The nodes of an element are fixed by the input file's ELEMent cards.

[casebolt]

Thank you for your answers.

Based off of what you are describing it sounds as though modifications to the corresponding ELEMent card subroutines would be the best approach, perhaps incorporating a separate nelm option.

Here is a diagram and explanation for what I am looking to do.
!                                   *         
!                                     6
!
!                        4            3
!                         * - - - - *         * 
!                         |  x   x  |          5
!                         |    e    |
!                         |  x   x  |
!                         * - - - - *       
!                        1            2         
The ix would need to be amended/created so that its 5th and 6th index would store another global address. The off element nodes to be evaluated over an element are related to the integration points (x) rather than the particulars of the meshing. So for instance 5 and 6 may have zero influence when looking at the first GP, but since the assembly is from the element, its address should be included on the element level to remain compatible with FEAP.

[FEAP_Admin]

I wonder if the best (and cleanest) strategy would be to use UFORMFE.F.

[casebolt]

I wonder if the best (and cleanest) strategy would be to use UFORMFE.F.

Is this a FEAP 7.4-8.6 specific subroutine?

[Prof. R.L. Taylor]

What is a reference for the particle method you are trying to implement?  From the previous discussion it does not seem that a classical FE form is the best format for the development.  How are quadrature points related to the particles involved?  As Professor Govindjee mentioned a uformfe structure related to particles may be better.

[casebolt]

What is a reference for the particle method you are trying to implement?  From the previous discussion it does not seem that a classical FE form is the best format for the development.  How are quadrature points related to the particles involved?  As Professor Govindjee mentioned a uformfe structure related to particles may be better.

Hello Professor Taylor,

For added background, I am a first year PhD student studying computational mechanics at UCSD under Professor JS Chen and am familiar with FEAP 7.4 from when I took CE 233 as a ME undergraduate at UCB.

Regarding references: I would recommend checking out, Meshfree and Particle Methods : Fundamentals and Applications. Specifically the following sections:
- Ch.5 Deals with the shape function construction for the Reproducing Kernel Particle Method.
- Ch.6.2 Deals with Gauss Quadrature as an introductory scheme for domain integration.
- Ch.10 Deals with an existing 2D implementation of the core particle method based in Matlab by a past graduate student.
Currently I am just working on implementing one of the simplest RKPM schemes in FEAP, see Ch.6.2, as an academic exercise.

Regarding quadrature points: RK shape functions are global, with each node having its own support size based off of its proximity to neighboring nodes. For integration over a domain, if the point being evaluated for a given integration scheme exists within a neighboring nodes support, then that nodes shape function will have a non-zero contribution during integration regardless of whether the node exists within the bounds of the domain being integrated. This is talked about in Ch.6 as one of the simplest schemes to incorporate with traditional FEM, though other schemes are discussed in later sections. (See Figure 6.4)

It would appear that uformfe.f is not included in my copy of FEAPpv. Is this exclusive to the full FEAP program?

References:
  Belytschko, T., Chen, J.-S., & Hillman, M. C. (2024). Meshfree and particle methods : fundamentals and applications. Wiley.

[Prof. R.L. Taylor]

Thank you for the reference. I will look at the work you cite and think about what is the best way to proceed.  Yes, uformfe is only in feap.