Author Topic: MESH command using PARTitions (Read 7439 times)

ivanruka · « **on:** March 01, 2018, 05:40:18 AM »

Hello!

I have a problem when using the MESH comand to change a material parameter during computation.

I am using a user element with 4 degrees of freedom in every node, and I'm using partitions to solve the problem:

PART
1 1 0 0
0 0 1 1

My code for computing the solution looks like this:

BATCh
DT,,0.01
LOOP,time,10
TIME
PART,,1
LOOP,iter,20
UTAN,,1
NEXT,iter
PART,,2
LOOP,iter,20
UTAN,,1
NEXT,iter
NEXT,time
END

BATCh
MESH,matchange
END

BATCh
DT,,0.01
LOOP,time,15
TIME
PART,,1
LOOP,iter,20
UTAN,,1
NEXT,iter
PART,,2
LOOP,iter,20
UTAN,,1
NEXT,iter
NEXT,time
END

In the file matchange, I copy the material set that I want to change, with the new value of the desired parameter. As it is written in the manual, the file matchange ends with the command END.

It is working fine when I have a monolithic solution procedure, but when I use partitions like it is shown in the example above, it doesn't compute the solution properly after the change of parameters.

Do you know where the issue could be?

Thanks in advance!

Prof. S. Govindjee · « **Reply #1 on:** March 01, 2018, 06:38:00 AM »

have you tried

Code: [Select]

show dor

Code: [Select]

show udto see if the parameters are begin properly read both before and after the mesh change.

ivanruka · « **Reply #2 on:** March 01, 2018, 07:32:29 AM »

I have checked this, and it is being properly read before and after the mesh change (the parameter value changes as it should).

I have checked the Lfile and Ofile, and it seems that after the mesh change he is not computing anything because the displacements are not updated. He just enters partition 1, and then partition 2, but nothing happens.

FEAP_Admin · « **Reply #3 on:** March 01, 2018, 02:33:36 PM »

Have you tried running the analysis in interactive mode? That may provide some clues to what is happening.

ivanruka · « **Reply #4 on:** March 01, 2018, 03:18:48 PM »

When I'm running this in interactive mode I can see that everything works perfectly until the mesh change (and the solution is computed in ~6 iterations). After the MESH command, the changed material parameter is being read properly, but no displacement increments are computed (now, it is just 2 iterations, one for part,,1 and one for part,,2). Just for info, I'm modelling a tension test with imposed displacements at the right hand side.

I have tried to look into pmacr3.f where the MESH command is defined, to see if there is anything that could prevent this from running properly for a case with partitions, buy I haven't found anything yet. As I have already mentioned, everything works fine for an example that doesn't use partitions.

Do you know if there is any other way to change a material parameter during computation, so I could try to implement that also?

Prof. R.L. Taylor · « **Reply #5 on:** March 01, 2018, 05:20:39 PM »

Can you post what is in the 'matchange' file. Since nothing happens after the change there must be a flag that is lost relating to the partitions.

Can you check to see if the equation array is still o.k. also. This can be done by giving the command
SHOW ID
Do before and after you change the b.c. to discover if this is preserved too.

It may be necessary to write a user function to do what you are changing -- are you sure only things in the 'd' or the 'ud' array are changed?

ivanruka · « **Reply #6 on:** March 02, 2018, 05:13:31 AM »

Hello professor,

Here is the 'matchange' file:

MATErial,2
USER,5
40000 0.2
500000 0.05
-280 6 0.05 1

END

In this case, the first value is the one that is being changed (before it was 20000, now it is 40000).

I have checked the equation arrays as you have suggested, and ID(:,:,2) is the same before and after the MESH command. However, ID(:,:,1) is not the same, and the problem probably lays here. Here is the ID array before the mesh change:

Matrix: ID
row/col 1 2 3 4 5 6
1 -1 1 3 5 7 9
2 -2 2 4 6 8 10
3 0 0 0 -1 0 0
4 0 0 0 0 0 0

Matrix: ID
row/col 7 8 9 10 11 12
1 -3 -4 13 15 17 19
2 11 12 14 16 18 20
3 0 0 0 0 0 0
4 0 0 0 0 0 0

Matrix: ID
row/col 13 14
1 21 -5
2 22 23
3 0 0
4 0 0

Matrix: ID
row/col 1 2 3 4 5 6
1 1 0 0 0 0 0
2 1 0 0 0 0 0
3 0 0 0 1 0 0
4 0 0 0 0 0 0

Matrix: ID
row/col 7 8 9 10 11 12
1 1 1 0 0 0 0
2 0 0 0 0 0 0
3 0 0 0 0 0 0
4 0 0 0 0 0 0

Matrix: ID
row/col 13 14
1 0 1
2 0 0
3 0 0
4 0 0

Matrix: ID
row/col 1 2 3 4 5 6
1 -1 0 0 0 0 0
2 -1 0 0 0 0 0
3 1 3 5 -1 8 10
4 2 4 6 7 9 11

Matrix: ID
row/col 7 8 9 10 11 12
1 -1 -1 0 0 0 0
2 0 0 0 0 0 0
3 12 14 16 18 20 22
4 13 15 17 19 21 23

Matrix: ID
row/col 13 14
1 0 -1
2 0 0
3 24 26
4 25 27

And here it is after the mesh change:

Matrix: ID
row/col 1 2 3 4 5 6
1 -1 -3 -5 -7 -9 -11
2 -2 -4 -6 -8 -10 -12
3 0 0 0 -1 0 0
4 0 0 0 0 0 0

Matrix: ID
row/col 7 8 9 10 11 12
1 -13 -15 -17 -19 -21 -23
2 -14 -16 -18 -20 -22 -24
3 0 0 0 0 0 0
4 0 0 0 0 0 0

Matrix: ID
row/col 13 14
1 -25 -27
2 -26 -28
3 0 0
4 0 0

Matrix: ID
row/col 1 2 3 4 5 6
1 1 0 0 0 0 0
2 1 0 0 0 0 0
3 0 0 0 1 0 0
4 0 0 0 0 0 0

Matrix: ID
row/col 7 8 9 10 11 12
1 1 1 0 0 0 0
2 0 0 0 0 0 0
3 0 0 0 0 0 0
4 0 0 0 0 0 0

Matrix: ID
row/col 13 14
1 0 1
2 0 0
3 0 0
4 0 0

Matrix: ID
row/col 1 2 3 4 5 6
1 1 0 0 0 0 0
2 1 0 0 0 0 0
3 1 3 5 -1 8 10
4 2 4 6 7 9 11

Matrix: ID
row/col 7 8 9 10 11 12
1 1 1 0 0 0 0
2 0 0 0 0 0 0
3 12 14 16 18 20 22
4 13 15 17 19 21 23

Matrix: ID
row/col 13 14
1 0 1
2 0 0
3 24 26
4 25 27

We can see that after the mesh change all the numbers in the first part are negative, that means that the equations are not active currently, ant that shouldn't behave like this.

The subroutine pmacr3.f calls psetid.f and pnewpr.f that are related to the ID equation numbers, so I'm going to check them.

And regarding your last question, only one value in the d array has to change, so probably it wouldn't be so complicated to write a user function that does this.

Prof. R.L. Taylor · « **Reply #7 on:** March 02, 2018, 01:40:59 PM »

In pmacr3.f where the call to pmesh is made there seems to be an erroneous call to pnewpr() after all the statements about the opti command -- my guess is that this should be inside the endif of the opti. Since if you do not change b.c. you do not need to recompute the equation numbers. I suspect somehow that this is doing the renumbering of the first block. I have not traced the fault as I do not have a problem to use.

The 'mesh' is checking if b.c. change and then it would do a renumbering. So there must be a bug somewhere. I will try to set up a partitioned problem to trace it. In the meantime test if omitting this call to 'pnewpr' fixes your problem

ivanruka · « **Reply #8 on:** March 03, 2018, 02:44:09 AM »

I have tried changing the pmacr3.f file as you suggested, and when I put this whole block of code for resetting and renumbering equations into the if-loop for opti, it works!!

So, all of this...

c Set ID to current boundary condition array

c Reset ID equation numbers

setvar = palloc(111,'TEMP1',nneq, 1)
call psetid(mr(id31),mr(np(31)+nneq),mr(np(33)),mr(np(111)),
& mr(np(32)),mr(np(240)),nie,ndf,nen,nen1,
& numel,numnp,nummat)
setvar = palloc(111,'TEMP1', 0, 1)

c Set region indicator so all active region elements are assembled

nreg = -1

c Compute new equation numbers and profile

call pnewpr()

... shoud go inside the opti loop.

I have tested this on a few examples with partitions, and everything seems to work fine now that the equations are not being renumbered.

Thank you so much for your help, I really appreciate it!

Prof. R.L. Taylor · « **Reply #9 on:** March 03, 2018, 09:47:17 AM »

While it fixed your problem for now, I still think there is a bug that caused the equations to be renumbered wrong. It should not have mattered if the renumbering was done or not, if the boundary conditions remained the same then it should have just renumbered to the original scheme.

Can you describe what you did when you went back to the mesh. Did you reinput all the material sets with different values for a parameter? Or something else?

ivanruka · « **Reply #10 on:** March 05, 2018, 02:00:01 AM »

Dear professor,

I agree with you, there must be some bug, because I didn't change the boundary conditions at all. When changing the mesh, I only reinput the values for the material set that is changing, and put a new value for one parameter.

If you have an idea of what tests to perform to find this bug, I will gladly help.

Prof. R.L. Taylor · « **Reply #11 on:** March 05, 2018, 01:37:12 PM »

You posted the batch commands used in your early message. Can you tell me what basic commands you have in (a) the mesh generation (e.g., just COOR, ELEM, BOUN, MATE ?? or what??); (b) any commands between the mesh END and the first BATCh command besides the PARTion data (c) any other BATCh commands before those you posted.

I will try to recreate the error -- I suspect a flag somewhere is in error.

ivanruka · « **Reply #12 on:** March 06, 2018, 12:50:50 AM »

I am attaching my input file, so you can see all the commands I am using.

FEAP_Admin · « **Reply #13 on:** March 06, 2018, 04:13:13 AM »

Please post the file 'matchange'.

ivanruka · « **Reply #14 on:** March 07, 2018, 12:43:12 AM »

Here is the 'matchange' file.

FEAP User Forum

News:

Author Topic: MESH command using PARTitions (Read 7439 times)

ivanruka

MESH command using PARTitions

Prof. S. Govindjee

Re: MESH command using PARTitions

ivanruka

Re: MESH command using PARTitions

FEAP_Admin

Re: MESH command using PARTitions

ivanruka

Re: MESH command using PARTitions

Prof. R.L. Taylor

Re: MESH command using PARTitions

ivanruka

Re: MESH command using PARTitions

Prof. R.L. Taylor

Re: MESH command using PARTitions

ivanruka

Re: MESH command using PARTitions

Prof. R.L. Taylor

Re: MESH command using PARTitions

ivanruka

Re: MESH command using PARTitions

Prof. R.L. Taylor

Re: MESH command using PARTitions

ivanruka

Re: MESH command using PARTitions

FEAP_Admin

Re: MESH command using PARTitions

ivanruka

Re: MESH command using PARTitions