Loading [MathJax]/jax/output/CommonHTML/jax.js

Metafor

ULiege - Aerospace & Mechanical Engineering

User Tools

Site Tools

You are here: metafor.ltas.ulg.ac.be » Commits » 2017 » Commit 2017-12-20
Trace:
commit:2017:12_20

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Next revision		Previous revision
commit:2017:12_20 [2017/12/20 09:30] – created boemercommit:2017:12_20 [2018/05/04 16:47] (current) – boman
Line 1: Line 1:
-====== Commit December 7, 2017 ======+====== Commit 2017-12-20 ======
  
-In this commit, the asperity crushing simulations in the generalized plane strain state created by Carretta were simplified as much as possible and corrected where necessary.  The scripts of these simulations can be found in:+In this commit, the asperity crushing simulations in the generalized plane strain state created by Carretta for the Metalub/Metafor coupling were simplified as much as possible and corrected where necessary.  The scripts of these simulations can be found in:
   * ''oo_meta\aspCrushing\tests\twoDHalf'';   * ''oo_meta\aspCrushing\tests\twoDHalf'';
   * ''oo_meta\aspCrushing\tools\twoDHalf''.     * ''oo_meta\aspCrushing\tools\twoDHalf''.  
Line 22: Line 22:
  
 Notice that the rolling direction in this model is aligned with the axis z, while the vertical axis is y since plane strain simulations are usually represented in the xy-plane.  In Metalub, the rolling direction is x and the vertical direction is y since cold rolling was first modeled in 2D.  To extend the model to 3D, even another but more general choice was made in the reference document by Boemer, i.e.  the rolling direction is x and the vertical axis is z.   Notice that the rolling direction in this model is aligned with the axis z, while the vertical axis is y since plane strain simulations are usually represented in the xy-plane.  In Metalub, the rolling direction is x and the vertical direction is y since cold rolling was first modeled in 2D.  To extend the model to 3D, even another but more general choice was made in the reference document by Boemer, i.e.  the rolling direction is x and the vertical axis is z.  
 +
 +
 +===== CMakeLists.txt =====
 +
 +The following line was added in the ''IF(MSVC)'' of the main CMakeLists.txt file to enable parallel compilation even without IncrediBuild:
 +
 +  SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /MP")
  
  
Line 59: Line 66:
 ¯l=2√3Rq/tanθ ¯l=2√3Rq/tanθ
  
-{{ :metalub:lubri:commits:2017:geotriang1.png?direct&400 }}+{{ :commit:2017:12_20:geotriangle1.png?direct&400 }}
  
 Concerning the mesh, C4 and C9 have the same number of nodes and the refinement increases near S3.  C3 and C7 have the same number of nodes and they are equally spaced.  The same is true for C6, C8 and C10.  The lubricant side can then be meshed by the transfinite mesher, while the strip side is meshed with Gen4 due to the less important number of nodes on C1 than on C4. Concerning the mesh, C4 and C9 have the same number of nodes and the refinement increases near S3.  C3 and C7 have the same number of nodes and they are equally spaced.  The same is true for C6, C8 and C10.  The lubricant side can then be meshed by the transfinite mesher, while the strip side is meshed with Gen4 due to the less important number of nodes on C1 than on C4.
Line 72: Line 79:
 This second geometry is relatively similar to the first one.  Hence, it can still be defined by ¯l and θ, on the left and right side.  The fillet between the left and right parts was introduced to keep the normal to the contact tool continuous.  Previously, it was required to have ¯ll=¯lr.  Otherwise, the simulation would not converge due to the non-continuous normal of the contact tool.  This shortcoming was solved by changing the mathematical operations and keeping the normal continuous. This second geometry is relatively similar to the first one.  Hence, it can still be defined by ¯l and θ, on the left and right side.  The fillet between the left and right parts was introduced to keep the normal to the contact tool continuous.  Previously, it was required to have ¯ll=¯lr.  Otherwise, the simulation would not converge due to the non-continuous normal of the contact tool.  This shortcoming was solved by changing the mathematical operations and keeping the normal continuous.
  
-{{ :metalub:lubri:commits:2017:geotriang2.png?direct&600 }}+{{ :commit:2017:12_20:geotriangle2.png?direct&600 }}
  
 The vertical position of the mean line of the roll asperity profile is computed based on the points P17, P18, P19, P20, P21 (which are connected by straight lines in this computation).  Before this commit, the points that are now P17 and P21 were not positioned on C14 and C9, respectively.  This is why, the computation of the position of the mean line was previously wrong.  Hence, the output results of the test battery changed for the cases ''triangle2Dry.py'' and ''triangle2Lub.py''. The vertical position of the mean line of the roll asperity profile is computed based on the points P17, P18, P19, P20, P21 (which are connected by straight lines in this computation).  Before this commit, the points that are now P17 and P21 were not positioned on C14 and C9, respectively.  This is why, the computation of the position of the mean line was previously wrong.  Hence, the output results of the test battery changed for the cases ''triangle2Dry.py'' and ''triangle2Lub.py''.
Line 83: Line 90:
 In this case, xy-coordinates are read from a file and interpolated by a cubic spline to model more realistic asperity profiles. In this case, xy-coordinates are read from a file and interpolated by a cubic spline to model more realistic asperity profiles.
  
-{{ :metalub:lubri:commits:2017:geospline.png?direct&500 }}+{{ :commit:2017:12_20:geospline.png?direct&500 }}
  
 The vertical position of the mean lines of the roll asperity profile is computed based on the points of the curve C7 (which are connected by lines segments in this computation). The vertical position of the mean lines of the roll asperity profile is computed based on the points of the curve C7 (which are connected by lines segments in this computation).
Line 101: Line 108:
  
 The material law of the **strip** is the ''EvpIsoHHypoMaterial'' (), i.e. the elasto-visco-plastic law with isotropic hardening ([[doc:user:elements:volumes:iso_hypo_materials|]]).  The specific isotropic hardening law is ''AutesserreIsotropicHardening'' ([[doc:user:elements:volumes:isohard|]]), also known as SMATCH law. The material law of the **strip** is the ''EvpIsoHHypoMaterial'' (), i.e. the elasto-visco-plastic law with isotropic hardening ([[doc:user:elements:volumes:iso_hypo_materials|]]).  The specific isotropic hardening law is ''AutesserreIsotropicHardening'' ([[doc:user:elements:volumes:isohard|]]), also known as SMATCH law.
 +
 +
 ===== Finite elements ===== ===== Finite elements =====
  
Line 106: Line 115:
  
 The previous drawback does not appear for the solid material of the **strip**.  Hence, the SRIPR method was used for the strip. The previous drawback does not appear for the solid material of the **strip**.  Hence, the SRIPR method was used for the strip.
 +
 +
 ===== Boundary conditions ===== ===== Boundary conditions =====
  
Line 126: Line 137:
  
 :!: ** One may criticize that this conversion factor should not be constant, since the strip speed along the roll bite is not constant.  Moreover, it is excessively small (6 mm/s) considering that classical cold rolling speeds range up to several meters per second. ** :!: ** One may criticize that this conversion factor should not be constant, since the strip speed along the roll bite is not constant.  Moreover, it is excessively small (6 mm/s) considering that classical cold rolling speeds range up to several meters per second. **
 +
 +
 ==== Out-of-plane thickness variation ==== ==== Out-of-plane thickness variation ====
  
Line 133: Line 146:
  
 It is important to notice that the previous conditions not only have to be taken into account when the lubricant and strip elements are defined but also when the interface pressure is imposed on the lower edge of the strip and when the lubricant pressure is imposed on the edges of the lubricant (upper, left or right). It is important to notice that the previous conditions not only have to be taken into account when the lubricant and strip elements are defined but also when the interface pressure is imposed on the lower edge of the strip and when the lubricant pressure is imposed on the edges of the lubricant (upper, left or right).
 +
 +
 ==== Side edges of the strip ==== ==== Side edges of the strip ====
  
 The horizontal displacement of the side edges of the strip is blocked since its width usually does not change significantly during cold rolling. The horizontal displacement of the side edges of the strip is blocked since its width usually does not change significantly during cold rolling.
 +
 +
 ==== Lower edge of the strip ==== ==== Lower edge of the strip ====
  
Line 144: Line 161:
 If the value is True, the interface pressure evolution computed in Metalub is applied to the lower edge of the strip.  The edge is thus again pushed upwards.  As mentioned before, it is important to take into account the out-of-plane thickness variation in the definition of this ''Traction2DElement''.  In fact, if the out-of-plane thickness of the strip increases, the area on which the interface pressure is applied increases, too.  Although, the interface pressure was previously applied to this lower area, the computation does not automatically take into account its increase, which results in more important resultant nodal forces.  Hence, the out-of-plane thickness variation of the strip is introduced in the definition of the ''Traction2DElement''.  The following figure illustrates what happens in the initial state (A) and when the elongation of the strip increases, if the previous condition is not taken into account (B) and if it is taken into account (C). If the value is True, the interface pressure evolution computed in Metalub is applied to the lower edge of the strip.  The edge is thus again pushed upwards.  As mentioned before, it is important to take into account the out-of-plane thickness variation in the definition of this ''Traction2DElement''.  In fact, if the out-of-plane thickness of the strip increases, the area on which the interface pressure is applied increases, too.  Although, the interface pressure was previously applied to this lower area, the computation does not automatically take into account its increase, which results in more important resultant nodal forces.  Hence, the out-of-plane thickness variation of the strip is introduced in the definition of the ''Traction2DElement''.  The following figure illustrates what happens in the initial state (A) and when the elongation of the strip increases, if the previous condition is not taken into account (B) and if it is taken into account (C).
  
-{{ :metalub:lubri:commits:2017:interfacepressureoutofplane.png?direct&500 }}+{{ :commit:2017:12_20:interfacepressureoutofplane.png?direct&500 }}
  
 Moreover, in the second case (imposed interface pressure), an additional constraint is introduced to impose that this edge remains horizontal via the ''EqualityDofConstraintsSet'' (internally, this is possible by associating the degrees of freedom of several nodes to a same degree of freedom). Moreover, in the second case (imposed interface pressure), an additional constraint is introduced to impose that this edge remains horizontal via the ''EqualityDofConstraintsSet'' (internally, this is possible by associating the degrees of freedom of several nodes to a same degree of freedom).
 +
 +
 ==== Edges of the lubricant ==== ==== Edges of the lubricant ====
  
Line 161: Line 180:
 In the previous version, the out-of-plane thickness evolution of the lubricant was not introduced in the definition of the traction element, but the pressure was multiplied explicitly by the out-of-plane thickness.  In this new version, it was included in the definition of the traction element by specially paying attention to the zone to which it is applied.  To illustrate this subtlety, the following figure shows the scenario in which the lubricant pressure from Metalub is only applied to the upper edge of the lubricant (not on the left and right edges of the lubricant).  Case (A) shows the initial state.  Case (B) shows the state in which the elongation of the strip is not taken into account.  Finally, case (C) shows what is currently implemented in the asperity crushing model, i.e. that the elongation of the strip (not of the lubricant!) is introduced in the ''Traction2DElement'', which is applied to the upper edge of the lubricant. In the previous version, the out-of-plane thickness evolution of the lubricant was not introduced in the definition of the traction element, but the pressure was multiplied explicitly by the out-of-plane thickness.  In this new version, it was included in the definition of the traction element by specially paying attention to the zone to which it is applied.  To illustrate this subtlety, the following figure shows the scenario in which the lubricant pressure from Metalub is only applied to the upper edge of the lubricant (not on the left and right edges of the lubricant).  Case (A) shows the initial state.  Case (B) shows the state in which the elongation of the strip is not taken into account.  Finally, case (C) shows what is currently implemented in the asperity crushing model, i.e. that the elongation of the strip (not of the lubricant!) is introduced in the ''Traction2DElement'', which is applied to the upper edge of the lubricant.
  
-{{ :metalub:lubri:commits:2017:lubricantpressureoutofplane.png?direct&600 }}+{{ :commit:2017:12_20:lubricantpressureoutofplane.png?direct&600 }} 
 + 
 ==== Contact interaction ==== ==== Contact interaction ====
  
Line 176: Line 197:
  
 :!: The out-of-plane thickness evolution of the strip was previously introduced in the definition of the contact interaction, to compute the actual contact area between the roll and the strip later on. ** I noticed, however, by some small tests, that the thickness evolution of the strip (when introduced in the contact interaction) is NOT taken into account in the contact area computation.  Hence, the relative contact area has to be computed differently than before.  This error was corrected in this commit (see the subsection about the "Relative contact area" in the "Extractors" section below). ** Hence, the out-of-plane thickness evolution of the strip has not to be introduced in the contact tool anymore. :!: The out-of-plane thickness evolution of the strip was previously introduced in the definition of the contact interaction, to compute the actual contact area between the roll and the strip later on. ** I noticed, however, by some small tests, that the thickness evolution of the strip (when introduced in the contact interaction) is NOT taken into account in the contact area computation.  Hence, the relative contact area has to be computed differently than before.  This error was corrected in this commit (see the subsection about the "Relative contact area" in the "Extractors" section below). ** Hence, the out-of-plane thickness evolution of the strip has not to be introduced in the contact tool anymore.
 +
 +
 ===== ALE ===== ===== ALE =====
  
Line 182: Line 205:
 Either Godunov's method or the finite volume linear reconstruction method (see [[doc:user:ale:ale|]]) can be used for the convection step with sub-stepping depending on whether ''conv'' is equal to ''godunov'' or ''benson''.  Only the pressure is convected.  More precisely, to compute the pressure, Metafor computes a pressure increment at each time step based on the bulk modulus and the volume variation of the lubricant elements.  To compute the pressure at the following time step it is therefore necessary to convect the pressure. Either Godunov's method or the finite volume linear reconstruction method (see [[doc:user:ale:ale|]]) can be used for the convection step with sub-stepping depending on whether ''conv'' is equal to ''godunov'' or ''benson''.  Only the pressure is convected.  More precisely, to compute the pressure, Metafor computes a pressure increment at each time step based on the bulk modulus and the volume variation of the lubricant elements.  To compute the pressure at the following time step it is therefore necessary to convect the pressure.
  
-According to Carretta, the velocities and accelerations were not convected because they made the convergence more difficult.+According to Carretta, the velocities and accelerations were not convected because they made the convergence more difficult/impossible.
  
 :?: ** Why is only the convection of the pressure sufficient?  Is this sufficient to model the creation of a pressure gradient due to a convergent effect? I am not sure, if it is a good idea to not convect the velocities and accelerations since they are at the cause of creating pressure gradients, which might lead to the microhydrodynamism. ** :?: ** Why is only the convection of the pressure sufficient?  Is this sufficient to model the creation of a pressure gradient due to a convergent effect? I am not sure, if it is a good idea to not convect the velocities and accelerations since they are at the cause of creating pressure gradients, which might lead to the microhydrodynamism. **
Line 222: Line 245:
 \end{equation} \end{equation}
  
-{{ :metalub:lubri:commits:2017:nodalcontactarea.png?direct&600 }}+{{ :commit:2017:12_20:nodalcontactarea.png?direct&600 }}
  
 As explained before (section about the "Contact interaction"), it is currently not possible to take into account the evolution of the out-of-plane thickness of the strip in the contact interaction.  In consequence, Metafor rather computes the nodal contact area as follows (lz,s=1.0):  As explained before (section about the "Contact interaction"), it is currently not possible to take into account the evolution of the out-of-plane thickness of the strip in the contact interaction.  In consequence, Metafor rather computes the nodal contact area as follows (lz,s=1.0): 
Line 242: Line 265:
  
 Previously mentioning the option ''AIC_ONCEPERSTEP'' in the definition of the contact interaction ensures that the values ai are updated after each time step. Previously mentioning the option ''AIC_ONCEPERSTEP'' in the definition of the contact interaction ensures that the values ai are updated after each time step.
 +
  
 ==== Distance between updated mean lines ==== ==== Distance between updated mean lines ====
Line 255: Line 279:
    * yM is the vertical position of the updated mean line of the strip profile.    * yM is the vertical position of the updated mean line of the strip profile.
  
-{{ :metalub:lubri:commits:2017:distmeanlineextr.png?direct&400 }}+{{ :commit:2017:12_20:distmeanlineextr.png?direct&400 }}
  
 While ym does not change during the computation since the tool is rigid, the mean line of the strip profile has to be updated based on its definition: While ym does not change during the computation since the tool is rigid, the mean line of the strip profile has to be updated based on its definition:
Line 263: Line 287:
 \end{equation} \end{equation}
  
-{{ :metalub:lubri:commits:2017:meanline.png?direct&600 }}+{{ :commit:2017:12_20:meanline.png?direct&600 }}
  
  
Line 294: Line 318:
 \end{equation} \end{equation}
  
-{{ :metalub:lubri:commits:2017:lubricantpressureextr.png?direct&600 }}+{{ :commit:2017:12_20:lubricantpressureextr.png?direct&600 }}
  
 Isolating the lubricant pressure applied to the strip pl eventually leads to the formula which is used to compute its value: Isolating the lubricant pressure applied to the strip pl eventually leads to the formula which is used to compute its value:
Line 301: Line 325:
 p_{l} = \frac{l_{z,l}}{l_{z,s}} \frac{1}{L_{nc}} \int -p \; c \; \text{d}s  = \frac{l_{z,l}}{l_{z,s}} \frac{1}{L_{nc}} \int -p(x) \; c \; \sqrt{1 + \left(\frac{\partial y}{\partial x}\right)^{2}} \; \text{d}x p_{l} = \frac{l_{z,l}}{l_{z,s}} \frac{1}{L_{nc}} \int -p \; c \; \text{d}s  = \frac{l_{z,l}}{l_{z,s}} \frac{1}{L_{nc}} \int -p(x) \; c \; \sqrt{1 + \left(\frac{\partial y}{\partial x}\right)^{2}} \; \text{d}x
 \end{equation} \end{equation}
- 
- 
- 
  
  
Line 325: Line 346:
   * Wrong computation of the mean line of the contact tool in the scenario with the two triangular half asperities (see the section related to the "Two triangular half asperities" for more details);   * Wrong computation of the mean line of the contact tool in the scenario with the two triangular half asperities (see the section related to the "Two triangular half asperities" for more details);
   * It was thought that the out-of-plane thickness evolution of the strip (introduced in the contact interaction) was taken into account to compute the nodal areas of the slave nodes.  But it was not.  Hence, the computation of the relative contact area included the out-of-plane thickness in the denominator, though it should not be included.   * It was thought that the out-of-plane thickness evolution of the strip (introduced in the contact interaction) was taken into account to compute the nodal areas of the slave nodes.  But it was not.  Hence, the computation of the relative contact area included the out-of-plane thickness in the denominator, though it should not be included.
 +
 +
 +===== Added [a] / deleted [d] / modified [m] / renamed [r] general files/folders ======
 +
 +<code>
 +
 +[m] CMakeLists.txt
 +
 +[m] aspCrushing/tools/python/rollingAsp.py
 +[r] aspCrushing/tools/python/aspCrush.py
 +
 +[m] aspCrushing/tools/python/aspExtractors.py
 +[r] aspCrushing/tools/python/aspExtr.py
 +
 +[d] aspCrushing/tools/python/bCondPb.py
 +
 +[m] aspCrushing/tools/python/evolutionFunction.py
 +[m] aspCrushing/tools/python/geoSpline.py
 +
 +[m] aspCrushing/tools/python/geoTriang.py
 +[r] aspCrushing/tools/python/geoTriangle1.py
 +
 +[m] aspCrushing/tools/python/geoTwoAsp.py
 +[r] aspCrushing/tools/python/geoTriangle2.py
 +
 +[m] aspCrushing/tools/python/Vector.py
 +
 +[d] aspCrushing/tests/twoDhalf/bCond
 +[r] aspCrushing/tests/twoDhalf/bc
 +[d] aspCrushing/tests/twoDhalf/bCond/res_bc_ht.ascii
 +[r] aspCrushing/tests/twoDhalf/bc/res_bc_ht.ascii
 +[d] aspCrushing/tests/twoDhalf/bCond/res_bc_lxx.ascii
 +[r] aspCrushing/tests/twoDhalf/bc/res_bc_lx.ascii
 +[d] aspCrushing/tests/twoDhalf/bCond/res_bc_lxx_lub.ascii
 +[r] aspCrushing/tests/twoDhalf/bc/res_bc_lx_lub.ascii
 +[d] aspCrushing/tests/twoDhalf/bCond/res_bc_p.ascii
 +[r] aspCrushing/tests/twoDhalf/bc/res_bc_p.ascii
 +[d] aspCrushing/tests/twoDhalf/bCond/res_bc_pb_rey.ascii
 +[r] aspCrushing/tests/twoDhalf/bc/res_bc_pl.ascii
 +[d] aspCrushing/tests/twoDhalf/bCond/res_bc_p.ascii
 +[r] aspCrushing/tests/twoDhalf/bc/res_bc_pi.ascii
 +
 +</code>
 +
 +
 +===== Added [a] / deleted [d] / modified [m] / renamed [r] test cases ======
 +
 +<code>
 +[m] aspCrushing/tests/twoDhalf/reelDry.py
 +[r] aspCrushing/tests/twoDhalf/splineDry.py
 +[m] aspCrushing/tests/twoDhalf/reelDry.tsc
 +[r] aspCrushing/tests/twoDhalf/splineDry.tsc
 +
 +[m] aspCrushing/tests/twoDhalf/reelLub.py
 +[r] aspCrushing/tests/twoDhalf/splineLub.py
 +[m] aspCrushing/tests/twoDhalf/reelLub.tsc
 +[r] aspCrushing/tests/twoDhalf/splineLub.tsc
 +
 +[m] aspCrushing/tests/twoDhalf/triang1Dry.py
 +[r] aspCrushing/tests/twoDhalf/triangle1Dry.py
 +[m] aspCrushing/tests/twoDhalf/triang1Dry.tsc
 +[r] aspCrushing/tests/twoDhalf/triangle1Dry.tsc
 +
 +[m] aspCrushing/tests/twoDhalf/triang1Lub.py
 +[r] aspCrushing/tests/twoDhalf/triangle1Lub.py
 +[m] aspCrushing/tests/twoDhalf/triang1Lub.tsc
 +[r] aspCrushing/tests/twoDhalf/triangle1Lub.tsc
 +
 +[m] aspCrushing/tests/twoDhalf/triang2Dry.py
 +[r] aspCrushing/tests/twoDhalf/triangle2Dry.py
 +[m] aspCrushing/tests/twoDhalf/triang2Dry.tsc
 +[r] aspCrushing/tests/twoDhalf/triangle2Dry.tsc
 +
 +[m] aspCrushing/tests/twoDhalf/triang2Lub.py
 +[r] aspCrushing/tests/twoDhalf/triangle2Lub.py
 +[m] aspCrushing/tests/twoDhalf/triang2Lub.tsc
 +[r] aspCrushing/tests/twoDhalf/triangle2Lub.tsc
 +</code>
 +
 +
 + --- // [[dominik.boemer@uliege.be|Dominik Boemer]] 2017/12/20 11:30 //
commit/2017/12_20.1513758653.txt.gz · Last modified: by boemer
Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki