Dear @KratosMultiphysics/structural-mechanics ,
While debugging my new embedded solver I realised that the structure was not converging for a simple POSITIVE_FACE_PRESSUREdistribution. I did extract such pressure load to set a simple structural mechanics problem with the same geometry. Some of you will note that it is the Mok benchmark beam but with a larger Young modulus.
I'm attaching the files so you can run it.
Many thanks in advance!
test_structure.zip
I believe that the problem is in the way the first residual is initialized:
we should compute the residual r0 BEFORE solving the system of equations, not after having updated the solution.
Having said this, we need to be careful in doing this in a way that is not affected by the MPCs, in the sense that the residual will not be zero there where the MPCs are acting, so master and slave dofs will have to be taken out from this computation.
Just to clarify things, I was using the residual_criteria
I believe that the problem is in the way the first residual is initialized:
we should compute the residual r0 BEFORE solving the system of equations, not after having updated the solution.
Having said this, we need to be careful in doing this in a way that is not affected by the MPCs, in the sense that the residual will not be zero there where the MPCs are acting, so master and slave dofs will have to be taken out from this computation.
We should differentiate external and internal forces (that's the key)
easier to say than to do...
also what would u do for the fluid?
to begin i would at least compute r(x0) correctly.
now we are computing r0 as r(x0+dx) (and btw we are computing twice the norm)
@RiccardoRossi I do what you propose in https://github.com/KratosMultiphysics/Kratos/pull/4286
@loumalouomega about differentiating internal and external forces you are surely right. along the same line we should also differentiate damping and inertia forces for dynamic problems.
my proposal would be to address this by implementing in the structural elements and conditions a
$Calculate(EXTERNAL_FORCES_VECTOR)$
the BuilderAndSolver could then assemble that. The nasty part of it is that than we would surely need to have an mpi version and a serial version of the convergence criterias to be able to do the assembly differently. Also for dynamic problems the convergence criteria would have to be aware of the scheme (which is not)
the BuilderAndSolver could then assemble that. The nasty part of it is that than we would surely need to have an mpi version and a serial version of the convergence criterias to be able to do the assembly differently. Also for dynamic problems the convergence criteria would have to be aware of the scheme (which is not)
maybe for this #859 could be used ...
ok, this is an option, still the only object that would know this is the convergence criteria (the strategy does not know of this behaviour) so we would have to pass the builder and solver and scheeme to the convergence criteria if you want to use that mechanism.
it might also make sense to explore some sort of modified build function to which a lambda function could be assigned
What is the resolution for this problem? We also have convergence problem for a simple test case. See attached file.
test_square_pressure.gid.zip
Just to be clear on what happens, we create a square and set symmetry condition on left and bottom side. The pressure is applied on top and the material is linear, small displacement element is used. The move_mesh_flag is disabled. The iteration did not converge in 10 steps. How come this is possible?
Just to be clear on what happens, we create a square and set symmetry condition on left and bottom side. The pressure is applied on top and the material is linear, small displacement element is used. The move_mesh_flag is disabled. The iteration did not converge in 10 steps. How come this is possible?
No idea, strange...
Hi all,
here is a benchmark example for StructuralMechanicsApplication of cylinder with applied internal pressure. I have tried to run it with both line load and pressure on the internal edge with linear and quadratic small displacement elements. I have obtained some strange behavior and I hope someone can help me understand it. Namely, for the Q4 element with line_load condition everything goes perfectly. For the same element with pressure condition, I have obtained the same result but after 5 iterations! (the move_mesh_flag is set to false)

For Q9 element with line load condition, I obtained wrong result, but the simulation converged in one iteration as it should. For pressure condition the simulation did not converge after 10 iterations.

I was thinking that it may be that I have mad a mistake in setting the boundary conditions for the quadratic case, however it seems all fine to me. I would appreciate greatly if someone can check the attached input files and provide some feedback. Is it possible that there is a bug somewhere in the line_load_condition_2d? Are there any other working examples with pressure and line load on small displacement element?
Best regards and thanks in advance! I wish a nice weekend to everyone.
Vladislav
I assume that the issue is in the line_load_condition. Which assumes that the line is only two nodes (which is wrong). If we add a general integration we will need anyway to update the interface for consistency.
For the pressure is strange, it the load is follower, but the mesh is not moving, should not matter.
I will check
@vgudzulic Respect the q4, I needed to update the test you send us and I added #4596 in order to be able to apply a load in a analytic direction so the resulting load is exactly the same. The pressure has as you said 5 iterations instead of 1, I am researching that right now.
@loumalouomega Thanks a lot for looking into it. Let me know if I can help somehow
@loumalouomega Thanks a lot for looking into it. Let me know if I can help somehow
Well, my theory is that the Line2D3 has some bug, I am creating tests right now.
@loumalouomega Thanks a lot for looking into it. Let me know if I can help somehow
Well, my theory is that the Line2D3 has some bug, I am creating tests right now.
The length computation was wrong for example
@loumalouomega Thanks a lot for looking into it. Let me know if I can help somehow
Well, my theory is that the Line2D3 has some bug, I am creating tests right now.
The length computation was wrong for example
#4601 Fixes the quadratic line, many things wrong or badly copypasted. The PR includes tests and fixes everything wrong (I found)
Hi all,
here is a benchmark example for StructuralMechanicsApplication of cylinder with applied internal pressure. I have tried to run it with both line load and pressure on the internal edge with linear and quadratic small displacement elements. I have obtained some strange behavior and I hope someone can help me understand it. Namely, for the Q4 element with line_load condition everything goes perfectly. For the same element with pressure condition, I have obtained the same result but after 5 iterations! (the move_mesh_flag is set to false)
For Q9 element with line load condition, I obtained wrong result, but the simulation converged in one iteration as it should. For pressure condition the simulation did not converge after 10 iterations.
I was thinking that it may be that I have mad a mistake in setting the boundary conditions for the quadratic case, however it seems all fine to me. I would appreciate greatly if someone can check the attached input files and provide some feedback. Is it possible that there is a bug somewhere in the line_load_condition_2d? Are there any other working examples with pressure and line load on small displacement element?
Best regards and thanks in advance! I wish a nice weekend to everyone.
Vladislav
Can you try #4601?
Hi,
line load using line2D3 is now working. Thanks a lot @loumalouomega !

Pressure still needs 5 iterations though, but gives the same result in both cases.
Hi,
line load using line2D3 is now working. Thanks a lot @loumalouomega !
Pressure still needs 5 iterations though, but gives the same result in both cases.
In my case it takes 2 iterations, are you considering 1.0e-4 for relative criteria or smaller?
@loumalouomega Yes, true, I am using 1.0e-09. If I set relative tolerance to 1.0e-04, it converges in 2 steps as you say. However, in case of small_displacement elements it should converge in one iteration. The only difference is in that in LINE_LOAD we give the direction to the load explicitly, whereas in POSITIVE_FACE_PRESSURE, the line_load condition computes it itself.
By the way, here is the convergence study for global error in stresses (h1) and displacements (l2) for this problem with a small_displacement element and applied line load. It shows perfect convergence now. When the PR is approved, we would like to submit this as an example for the StructuralMechanicsApplication, and possibly as a nightly test.

@loumalouomega Yes, true, I am using 1.0e-09. If I set relative tolerance to 1.0e-04, it converges in 2 steps as you say. However, in case of small_displacement elements it should converge in one iteration. The only difference is in that in LINE_LOAD we give the direction to the load explicitly, whereas in POSITIVE_FACE_PRESSURE, the line_load condition computes it itself.
By the way, here is the convergence study for global error in stresses (h1) and displacements (l2) for this problem with a small_displacement element and applied line load. It shows perfect convergence now. When the PR is approved, we would like to submit this as an example for the StructuralMechanicsApplication, and possibly as a nightly test.
Feel free to approve (wink wink)
I reopen, because we still have some problem of convergence (I think)
@vgudzulic feel free to create the test
@vgudzulic why do you disable the move_mesh flag?
@RiccardoRossi @loumalouomega isn't this required for StructuralMechanics?
@philbucher Because I don't want the mesh to move (this is a small displacement element so I want everything to be computed in the reference configuration). At the time when I started preparing this example I was not getting correct results so I thought that move_mesh_flag was an issue, so I disabled it. I checked now with the move_mesh_flag=true and there is no side effect when the LINE_LOAD condition is used, because the solution converges in one iteration. However, with pressure, it causes slight change in the final result (it gets worse) but the number of iterations stays the same (2 for relative tolerance 10^-04 and 5 for tolerance 10^-09).
@loumalouomega I will try to prepare some test in the following days
We solved this, can we close it?
Hi Vlad
Is the line load with PRESSURE working as expected?
On Mon, May 6, 2019, 19:41 Vicente Mataix Ferrándiz <
[email protected]> wrote:
We solved this, can we close it?
—
You are receiving this because you are on a team that was mentioned.
Reply to this email directly, view it on GitHub
https://github.com/KratosMultiphysics/Kratos/issues/4272#issuecomment-489606060,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADJEUSTD4KFGMQD5DS67JB3PUARP5ANCNFSM4G2KMIIQ
.
I believe that the pressure should converge in one step in this case, so far it is not. Line load works perfectly. I promised to make some tests, but, unfortunately, I never got time to look into that. I would keep it open if others agree
Hi,
related to this issue, I have made two tests that verify that the rhs is computed correctly even for curved geometries (one for curved line and one for curved triangle) which I could provide if needed. The value is correct and is not a cause for the fact that for small displacement element the solution doesn't converge in one step (even with move_mesh_flag set to false). The problem is in fact the load stiffness that should be a zero matrix in case of small displacements, as a linearization of rhs (since the normal doesn't change). This is currently not possible due to the fact that the condition is the same for small displacement, TL, and UL and it is always assumed that everything is computed on deformed configuration as already discussed in #5890.
I tried that as well locally and when I find Jacobian on reference configuration and set the lhs contribution to zeros explicitly, I obtain the correct convergence in one step.
With this conclusion, I think we know the cause of the problem and maybe this issue is not necessary anymore.
Regards
Vladislav
Hi,
related to this issue, I have made two tests that verify that the rhs is computed correctly even for curved geometries (one for curved line and one for curved triangle) which I could provide if needed. The value is correct and is not a cause for the fact that for small displacement element the solution doesn't converge in one step (even with move_mesh_flag set to false). The problem is in fact the load stiffness that should be a zero matrix in case of small displacements, as a linearization of rhs (since the normal doesn't change). This is currently not possible due to the fact that the condition is the same for small displacement, TL, and UL and it is always assumed that everything is computed on deformed configuration as already discussed in #5890.I tried that as well locally and when I find Jacobian on reference configuration and set the lhs contribution to zeros explicitly, I obtain the correct convergence in one step.
With this conclusion, I think we know the cause of the problem and maybe this issue is not necessary anymore.
Regards
Vladislav
@RiccardoRossi and me faced this same problem when implementing the mixed u-eps_vol element a few weeks ago.
We agreed that we should (sooner than later) implement a load condition for small displacement elements.
yes, as described in #5890 right now we have surely a problem in the case of non negligible deformations. I think it is actually quite important to implement integration on the reference configuration for such cases