*NODe / *ELEment usage

[JStorm]

My intention is to add 2 single elements after some previous meshing routines (FEAP 8.4). E.g., I already have 12 nodes and 5 elements in the mesh.

Code: [Select]

*NODe    = 12
*ELEment = 5

LOOP,2

  COORDINATES
    1 0   -1. -1.
    2 0   -1. -1.
    3 0   -1. -1.
    4 0   -1. -1.
   
  ELEMents
    1 0 1   1 2 3 4

NEXT
I am note sure, whether I missanderstand *NODe/*ELEment or there is a bug in pnums.f. My expectation on this feature is to end up with 20 nodes and 7 elements.

Thus, instead of

Code: [Select]

numn = max(numn,(num+starnd)*loop_t)I would expect something like

Code: [Select]

numn = max(numn,num*loop_t+starnd)in numps.f

Further, I recognised that "numn" is not shared with the user mesh routines umesh*.f, which would allow them to increment IDs by them self like BLEnd and BLOCk can do. I suggest to change that interface or to put numn into a common block.

[Prof. R.L. Taylor]

1. The use of *node and *elem apply to each quantity following the input.  Thus if you do not change it during the LOOP it does the same thing to each loop.  See attached input for an example

2. We use unumnd nd unumne for the user inputs and after exiting combine with the numn and nume, does this cause a problem in what you want to do?

[Prof. R.L. Taylor]

One other comment.  Ver 8.5 adds another option called *auto which does more things automatically.

[JStorm]

1. The use of *node and *elem apply to each quantity following the input.  Thus if you do not change it during the LOOP it does the same thing to each loop.  See attached input for an example

I have extended your example to point out my issue. Now, there are 12 nodes and 2 elements in the mesh before entering the loop. The example leads to 80 nodes and 30 elements instead of the expected 12+5*4=32 nodes and 5+5*1=10 elements.

If you check pnums.f for your example, then this is only working because *NODe and *ELEments are not recognised (equal 0) there. Otherwise, the number of nodes and elements created for the loop are wrong.

A modification of pnums.f to

Code: [Select]

numn = max(numn,num*loop_t+starnd)
...
nume = max(nume,num*loop_t+starel)
...
numn = max(numn,unumnd*loop_t+starnd)
nume = max(nume,unumel*loop_t+starel)
would fix the behaviour.

By the way, the manual about *NOD/*ELE is not so clear (for me). I had to look into the code to understand, that this defines an ID offset only.

2. We use unumnd and unumne for the user inputs and after exiting combine with the numn and nume, does this cause a problem in what you want to do?

This is not causing a problem. But it requires that umesh*.f asks for the last node and element ID used in the mesh so far to calculate the new number of nodes and elements into unumnd / unumne. It would be nice to have numn/nume at hand in umesh*.f to identify the last node and element ID automatically.

One other comment.  Ver 8.5 adds another option called *auto which does more things automatically.

Thank you for that hint. But my code for the linear constraints are not ported to FEAP 8.5 yet and my simulations rely on that feature.

From the code in pnums.f for FEAP 8.5 the *AUTo feature is really nice. But the calculation of the node and elements numbers is wrong, too. The modifications mention above also needs to be applied.

To overcome the missing information about the last node and element ID in umesh*.f, the *AUTo feature should also effect the user mesh routines by adding

Code: [Select]

if(starfl) then
  starnd = numn
  starel = nume
endif
Than there is no need to provide numn/nume to umesh*.f and the interface can be preserved. (The ID incrementation is done by pnums.f and the current IDs in umesh*.f can be identified from dstar.h, when it is called from pmesh.f)

[JStorm]

Code: [Select]

numn = max(numn,num*loop_t+starnd)
...
nume = max(nume,num*loop_t+starel)
...
numn = max(numn,unumnd*loop_t+starnd)
nume = max(nume,unumel*loop_t+starel)


Dear Prof. Taylor,
please can you check the proposed modifications to pnums.f and give me a hint, if I misunderstood how to use it the right way?

[Prof. R.L. Taylor]

Your proposed changes seem to fix the problem you posed.   I worry there are other forms and that they remain correct too.   I will try a sequence of problems to test more.

[JStorm]

Thank you for your feedback Prof. Taylor.