Kratos: explicit mpcs slave-master relation

Created on 15 Mar 2019  Â·  78Comments  Â·  Source: KratosMultiphysics/Kratos

Hi I have the following setup:
imp
the master nodes are on the light blue line and two slave nodes are at the connection between the dark and the light blue line. A force is applied at the right lower node and as you can see in the video above I can realize a sliding on the light blue line by coupling DISP_Y and DISP_Z between master and slave + searching new neighbour nodes in each iteration (not completely correct sliding but I will improve this...). This is using the implicit dynamic scheme.

I now wanted to try the new explicit mpcs and this is the result:
exi
One can see that the master line does not deform, but the constraints are properly set.

I think the problem is that in the current implementation of the explicit mpcs the load is not transferred to the master line. My guess would be that we have to couple the residual in void ExplicitCentralDifferencesScheme::Update of the slave and the master dof. Because they are in a certain relation, which is not considered at the moment.

I would be happy about any suggestions.

Help Wanted

All 78 comments

I will take a look on Monday's morning, sorry if I have broke/done
something wrong.

El vie., 15 mar. 2019 15:02, Klaus Bernd Sautter notifications@github.com
escribió:

Assigned #4456 https://github.com/KratosMultiphysics/Kratos/issues/4456
to @loumalouomega https://github.com/loumalouomega.

—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/KratosMultiphysics/Kratos/issues/4456#event-2206420617,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ATEMgOkGlPkG4WhtKTTTc_kxZAJLlnx9ks5vW528gaJpZM4b2cjw
.

Indeed there is a relation, sorry if I haven't seen that.

El vie., 15 mar. 2019 17:03, Vicente Mataix Ferrándiz <
[email protected]> escribió:

I will take a look on Monday's morning, sorry if I have broke/done
something wrong.

El vie., 15 mar. 2019 15:02, Klaus Bernd Sautter notifications@github.com
escribió:

Assigned #4456 https://github.com/KratosMultiphysics/Kratos/issues/4456
to @loumalouomega https://github.com/loumalouomega.

—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/KratosMultiphysics/Kratos/issues/4456#event-2206420617,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ATEMgOkGlPkG4WhtKTTTc_kxZAJLlnx9ks5vW528gaJpZM4b2cjw
.

I will take a look on Monday's morning, sorry if I have broke/done something wrong.

nothing wrong, I think there is sth. missing. I talked to @adityaghantasala and one way to go would be to check in Update if a dof of the current node is a slave dof. If yes we add the weighted residual, nodal mass, etc. to the master node

@loumalouomega I made a first try.
Sth. like edf9d8184ceca17e57ea61ce699373683077575c
But we can discuss this on monday

@Klaus did this approach work .. !!

On Fri, 15 Mar 2019, 19:08 Klaus Bernd Sautter, notifications@github.com
wrote:

@loumalouomega https://github.com/loumalouomega I made a first try.
Sth. like edf9d81
https://github.com/KratosMultiphysics/Kratos/commit/edf9d8184ceca17e57ea61ce699373683077575c
But we can discuss this on monday

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/KratosMultiphysics/Kratos/issues/4456#issuecomment-473389587,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACaf9CvLC_1zlH06wRMGSV0jgopxfsfWks5vW-G4gaJpZM4b2cjw
.

@adityaghantasala It seems to work. I get strange unsymmetric behaviour but this must be a problem with my code. I'll look more into this

new_exp

like that. But I guess this shows that the basic idea will work

Looks like force is transferred property on one side and not the other .. !

Just one thing, added to the constraint utilities, so everyone can use it.

El vie., 15 mar. 2019 20:00, Klaus Bernd Sautter notifications@github.com
escribió:

@adityaghantasala https://github.com/adityaghantasala It seems to work.
I get strange unsymmetric behaviour but this must be a problem with my
code. I'll look more into this

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/KratosMultiphysics/Kratos/issues/4456#issuecomment-473393375,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ATEMgLSDDMKoxupL4ej7Lpo6aBx8vT-bks5vW-R0gaJpZM4b2cjw
.

I just look the code, we can discuss further. But I don't agree on using
flags, mpc should not depend on flags. Have a nice weekend.

El vie., 15 mar. 2019 20:29, Vicente Mataix Ferrándiz <
[email protected]> escribió:

Just one thing, added to the constraint utilities, so everyone can use it.

El vie., 15 mar. 2019 20:00, Klaus Bernd Sautter notifications@github.com
escribió:

@adityaghantasala https://github.com/adityaghantasala It seems to
work. I get strange unsymmetric behaviour but this must be a problem with
my code. I'll look more into this

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/KratosMultiphysics/Kratos/issues/4456#issuecomment-473393375,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ATEMgLSDDMKoxupL4ej7Lpo6aBx8vT-bks5vW-R0gaJpZM4b2cjw
.

Which flag?

IS_SLAVE ?

I think yes ... we have been avoiding to use it ... and soon this flag will not be set even if the node has a slave DOF.
In stead you could directly search in the MasterSlaveContainer of the modelpart itself.

I deletetd the flag and rewrote the code: 6fcd282

still, this is only a rough idea and I think it would be nice to add this to the mpc_util in the end

another question would be if one has to couple also VEL and ACC now when I coupled only DISP using implicit dynamics

OK @adityaghantasala just told me that also VEL and ACC has to coupled in this case.
The new approach 6fcd282 works for me. @loumalouomega . So you might check this out.

@KlausBSautter in which branch are these developments?

Fine, can I refactor this?

yes please go ahead. It's just a rough idea how to realize this interaction

Thanks, let me a moment

Do we have a test for this?

no I have not done any explicit mpcs yet. But the examples I run with implicit mpcs give me now the same result with explicit mpc. E.g. the example I posted in this issue.

Can you attach the case?, I cleaned upda and generized and OMP teh code, but the current implementation will work only for MPC with one Dof at a time. A distributed operation with matrix operation must be done in order to correctly computed the explicit MPC. I will do that now

wouldn't a generalized Apply function on the constraint make more sense?

=> instead of using the dof-variable use an external variable but do the same operations

wouldn't a generalized Apply function on the constraint make more sense?

=> instead of using the dof-variable use an external variable but do the same operations

This is not applicable here because there is no way to know the residual variable used on explicit contributions relatable to the standard dofs.

thats what I mean, this variable (in the explicit case the residual variable) would be an additional argument

I mean, the global problem is that the same operation has to be applied to the constrained variables AND also to other variables (e.g. the residual-variable)

thats what I mean, this variable (in the explicit case the residual variable) would be an additional argument

I mean, the global problem is that the same operation has to be applied to the constrained variables AND also to other variables (e.g. the residual-variable)

I don't undertstand

Can you attach the case?

You would need an additional process. Should I commit that? We can later get rid of it again

Ok, I will push my changes and you can test it

Guys I am looking at this right now and just to say this is really messy & inefficient, we need a better solution for this ...

we just spoke in person; @KlausBSautter will try if this works properly, then we will try to find a proper & general solution that can go into master

Guys I am looking at this right now and just to say this is really messy & inefficient, we need a better solution for this ...

I am going to push a better solution in a moment

ok :+1:

Done, look at it now

I just saw that I can optimize it a little bit more. one sec

looks better!
only problem I have is the pGetNode, this is a find and a killer in large problems.
So far though I could not think of a better solution though

looks better!
only problem I have is the pGetNode, this is a find and a killer in large problems.
So far though I could not think of a better solution though

Yes, I have an idea...

@loumalouomega using the current branch, my examples don't converge with implicit mpcs anymore and

RuntimeError: Error: Variable is not a component or a double

is thrown with explicit mpcs

That't why I asked for a test, I implemented blindly. Sorry

I found the error, try now, sorry. I will create a test for it

ok but I wonder why the implicit example does not work anymore. I think the newest changes in the residual crit caused that.... ??

ok but I wonder why the implicit example does not work anymore. I think the newest changes in the residual crit caused that.... ??

Which examples?, are in the repository?

Can you attach the case?

You would need an additional process. Should I commit that? We can later get rid of it again

If it is just one file you can send me via private message.

No my local example, the one I posted here at the beginning.
Anyway there is still a problem with the explicit too

what(): Error: Dof variable is not defined

when coupling vel, acc etc.

also when I couple only disp this does not work anymore for explicit mpcs. wait I'll send you the example

https://gigamove.rz.rwth-aachen.de/d/id/jqCd8VNkCszUa6

you'll have to add the process which is included

Ok, thanks

one very strange thing. if you change the time int to implicit and couple only disp it does not converge anymore in the terminal and stays at the same res all the time. Eventhough the post pro file looks the same as before

The changes in this branch are affecting only to explicit things, I assume it is due to recent changes...

yes I found the mistake with the implicit scheme

Now it works with explicit

Only implicit...

The problem of implicit are that VELOCITY and ACCELERATION are reactionless

@RiccardoRossi FYI, the block B&S is failing with this case. Check the example posted by @KlausBSautter

@loumalouomega here this is alright I guess. When you do this example implicit you only couple DISP, as the rest is calculated implicitly from this solution. There was another problem but @philbucher and I just fixed it (see #4478).

When doing the explicit coupling you have to couple also VEL&ACC

I'll try your newest changes now with explicit

@loumalouomega it does not do what it did this morning, before refactoring
Now:
new_exp
before:
imp

OK, I will check out

@loumalouomega here this is alright I guess. When you do this example implicit you only couple DISP, as the rest is calculated implicitly from this solution. There was another problem but @philbucher and I just fixed it (see #4478).

When doing the explicit coupling you have to couple also VEL&ACC

This means that the scheme lacks of update for velocity and acceleration when displacement is known?

which scheme?

The explicit one, in the same way we do in the implicit ones.

I think in the implicit one the displacement is the solution which we use to update vel and acc. In explicit the solution is acc which we use to update disp and vel

yes, indeed, now we need to think a automatic way to link this instead of specify manually

maybe just couple the respective vel and acc if disp is coupled

Yeah, I was thinking something more generic

Maybe I found the problem, not sure .....

why are you transforming the master solution and add this to the slave?

It should be the other way round

yes makes it better but still not completely correct

Well the solution of the slave should depend on the master dofs...maybe I did it in an inverse sense...

yes the solution of the slave is preset by the constraints you do this after Update
But the solution of the master is dependent on the stiffness and mass which is added by the slaves too, this is what we do before Update. So we should add the residual of the slave to the residual of the master. We also have to think about how to add the mass

Ok, I understood your implementation wrong, well this has an easy solution

Sorry

Now it works and gives exactly the same solution

yes, perfect thanks !

For systems with larger masses we might experience problems, if we neglect the mass transfer (which we do right now)

For systems with larger masses we might experience problems, if we neglect the mass transfer (which we do right now)

Maybe we can do that in a future PR. We need o apply Steiner too to transfer inertias

yeah alright. So new PR with this new code ?

yeah alright. So new PR with this new code ?

Feel free

Was this page helpful?
0 / 5 - 0 ratings