Eng-Tips is the largest engineering community on the Internet
Intelligent Work Forums for Engineering Professionals
-
Congratulations waross on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Big time steps for Explicit/small time steps for Implict 5
- Thread starter mdama
- Start date
-
1
- #2
In explicit time steps have to be sufficiently small - stable time increment is calculated for all elements (based on Courant number) and the lowest value is used for the analysis. In implicit, there's no such limitation and time steps can be arbitrarily large. They can also be quite small but usually not as small as in explicit. In practice though, the solver automatically adjusts increments during the analysis to obtain convergence - reduces time step if convergence is poor and increases it if convergence is good. You can provide an initial guess or switch to fixed time incrementation but the latter is not recommended. In explicit you don't have to worry about convergence.
-
2
- #3
Coreform_Greg
Mechanical
There are two main categories of physics problems that we like to solve with FEA -- static problems and dynamic problems. Then there are two ways to formulate the systems of equation that arise from these problems: implicit systems of equations and explicit systems of equations.
While we often associate "explicit" with "explicit dynamics" this is not a requirement. It is completely possible to solve a statics problem with an explicit solver. We often accomplish this by adding a quantity with temporal dependence (e.g. mass) to our system of equations. If we add mass to a solid-mechanics problem we'll then increase the mass in each element to raise the critical timestep and we make sure that we've obtained a sufficiently quasi-static solution. This approach is typically called explicit quasistatics.
Of course, we often do have dynamic problems. For dynamic problems (or (quasi)static problems that we've coupled to time as described in the preceding paragraph) we typically formulate these using a semi-discrete approach... essentially, we discretize the spatial dimension with a mesh and then treat the time dimension as an ordinary differential equation (ODE). Solve the PDE at each discrete point in space as dictated by the time integration scheme. The choice of the time integration scheme dictates whether the entire system is either formulated as an implicit system or explicit system of equation and we call the integration scheme either "an implicit" or "an explicit" scheme based on how it formulates the system. ALL ODE integrators have stability requirements/criteria. All (to my knowledge) explicit ODE (time) integrators have a critical step-size, many implicit integrators have a critical step-size, and (luckily) some implicit integrators have no (finite) critical step-size.
What are stability requirements, effectively? Well, for a given integrator it can "control" the eigenvalues of the system. Eigenvalues form a basis for the solution... if the integrator can't "control" or even amplifies any eigenvalue, that eigenvalue might "blow up" to infinity (and beyond)! So regardless of whether you're using an explicit or implicit integrator, violating stability requirements (i.e. exceeding critical timestep) means you are no longer stable... your solution might blow up... it might not if you only violate it for one or two timesteps every so often... but you wanna take that risk? How do we compute a stable increment? Typically by computing the maximum eigenvalue and making sure that our timestep is no larger than the period of the frequency associated with said eigenvalue. Computing eigenvalues are expensive, however... it's essentially a linear solve so we often compute the max eigenvalue and then assume it doesn't change much over the next 100-1000 timesteps (valid for many problems), or at least might not change by more than ~5-10%. So we'll "scale" the stable timestep by some factor (typically 0.9 or 0.95) just to be safe. Interestingly, while we often talk about the effect of exceeding the explicit timestep, there are also issues with taking too small a timestep! Essentially, due to truncation and round-off errors as you decrease your timestep below the critical timestep you get closer and closer to solving (for solid-mechanics) a mass-spring system instead of a stress-wave propagation problem. So this is why you wouldn't want to choose a scale-factor of 0.01 or 0.001 for your stable timestep and then (probably) never have to recompute it.
Often within nonlinear static problems we use continuation methods (aka homotopy methods)to solve them. The general idea here is to solve the problem in a sequence where you "scale" the physics of the problem by some parameter, call it ε, at each iteration in the sequence. You use each solution to each scaled problem as the input to the next problem, with a slightly large value of ε. This ε is what codes like Abaqus call "Step Time" in their implicit static solvers. Furthermore, we often use this ε parameter as a "pseudo-time" quantity to "hack" time into our problem. For example we might model the manufacturing process of coiling a wire spring as a statics problem and use an implicit solver within a continuation method. The wire might have a temperature that we want to conduct and convect to the environmnet as well as plastically deform due to moving through space and contacting the tooling. The plasticity model might even be "rate-dependent". In such a case we might have ε vary from 0 to 2.5 and tell the solver to treat ε as time within the material, contact, and interaction models. As a sidenote, we can consider the explicit quasi-statics approach of the previous paragraph to be a continuation method.
Another important thing to mention is that we often use Newton's method to solve nonlinear implicit FEA problems. In Newtons method, we linearize the nonlinear system of equations and solve the linearized system. We then "plug" the linear solution back into the nonlinear equations, re-linearize, resolve... repeat until we converge. This linear solve portion is important to remember for later. There are other methods of solving these nonlinear problems such as nonlinear conjugate gradient (see Sandia's "Sierra/Solid-Mechanics" solver) or (more generally) Jacobian-free Newton-Krylov methods (see Idaho National Labs' "MOOSE" code).
So let's take a moment state the four categories of [tt]solver-problem[/tt] that we described above:
[ul]
[li]Explicit-Dynamic[/li]
[li]Explicit-(quasi)Static[/li]
[li]Implicit-Dynamic[/li]
[li]Implicit-(quasi)Static[/li]
[/ul]
There are some general rules of thumb that we can use to compare the cost of explicit and implicit solvers. (Imagine me giving the "rough handwavey" gesture throughout).
[ol 1]
[li]A single linear system solve in a Newton iteration is often at least ~100x as expensive as a single explict timestep. Newton's Method may require multiple iterations (i.e. multiple linear solves) to converge. And every time you relinearize, you have to update your element Jacobians / perform integration / reassemble... so in practice a single nonlinear solution may be 1000x (or more) as expensive as a single explicit solve.[/li]
[li]Even in a dynamics problem, there is still usually a "maximum physics frequency" that the engineer cares about which may be different than the "maximum frequency driving the problem". For instance, in the coiling of the wire spring, we could very-well model this as a dynamic problem. However, the engineer probably doesn't care about capturing physics that occur at super-high frequencies. They don't need to resolve the stress wave, just the averaged effect of stress. An explicit solver's critical timestep is often much smaller than the physics the engineer cares about. For example the stable timestep for the (explicit) coil problem might be 1e-10 seconds, which is capturing way more physics than the engineer actually needs. An implicit dynamic approach might give them a critical timestep of 1e-3 seconds and an implicit static approach might allow them to have Δε of ~5e-2 while achieving satisfactory results[/li]
[li]So why not always use implicit methods? The first is because sometimes the engineer does need to resolve very high-frequency physics to obtain good results. In a car-crash, for example, there are a lot of objects that are deforming rapidly and making contact with their closeby neighbors. And its this contact that is the principle driver behind their deformations, therefore nonlinear contact needs to be satisfactorily resolved, and thus a small timestep is required. Even if we were to solve this with implicit techniques, we would still need to advance at timesteps that can sufficiently resolve the contact... maybe only 1.5x-5x larger than the explicit timesteps. In these cases, it's simply faster to solve the problem using an explicit formulation![/li]
[li]Another reason to not use an implicit method is that a problem may have poor conditioning that causes the linear & nonlinear problems with converging. While my advice is that this should be a signal to improve your problem's conditioning (e.g. better mesh quality, change quadrature scheme, etc.) many engineers will switch to explicit because "it'll just solve". Often times, this is when the explicit-(quasi)static approach is used. They'll apply mass-scaling to bring the stable timestep up from 1e-10 seconds to maybe 1e-6 seconds which allows them to get a solution in a reasonable amount of time. Many times this explicit-(quasi)static approach "has" to be taken as improving the conditioning might be practically impossible. For instance, it might require increasing the mesh density so much that the problem is too larger for their computing resources. I've seen this IRL - a 10M element model needed ~250M elements to achieve good conditioning! We didn't have enough RAM on our 100-node HPC run this problem![/li]
[/ol]
While we often associate "explicit" with "explicit dynamics" this is not a requirement. It is completely possible to solve a statics problem with an explicit solver. We often accomplish this by adding a quantity with temporal dependence (e.g. mass) to our system of equations. If we add mass to a solid-mechanics problem we'll then increase the mass in each element to raise the critical timestep and we make sure that we've obtained a sufficiently quasi-static solution. This approach is typically called explicit quasistatics.
Of course, we often do have dynamic problems. For dynamic problems (or (quasi)static problems that we've coupled to time as described in the preceding paragraph) we typically formulate these using a semi-discrete approach... essentially, we discretize the spatial dimension with a mesh and then treat the time dimension as an ordinary differential equation (ODE). Solve the PDE at each discrete point in space as dictated by the time integration scheme. The choice of the time integration scheme dictates whether the entire system is either formulated as an implicit system or explicit system of equation and we call the integration scheme either "an implicit" or "an explicit" scheme based on how it formulates the system. ALL ODE integrators have stability requirements/criteria. All (to my knowledge) explicit ODE (time) integrators have a critical step-size, many implicit integrators have a critical step-size, and (luckily) some implicit integrators have no (finite) critical step-size.
What are stability requirements, effectively? Well, for a given integrator it can "control" the eigenvalues of the system. Eigenvalues form a basis for the solution... if the integrator can't "control" or even amplifies any eigenvalue, that eigenvalue might "blow up" to infinity (and beyond)! So regardless of whether you're using an explicit or implicit integrator, violating stability requirements (i.e. exceeding critical timestep) means you are no longer stable... your solution might blow up... it might not if you only violate it for one or two timesteps every so often... but you wanna take that risk? How do we compute a stable increment? Typically by computing the maximum eigenvalue and making sure that our timestep is no larger than the period of the frequency associated with said eigenvalue. Computing eigenvalues are expensive, however... it's essentially a linear solve so we often compute the max eigenvalue and then assume it doesn't change much over the next 100-1000 timesteps (valid for many problems), or at least might not change by more than ~5-10%. So we'll "scale" the stable timestep by some factor (typically 0.9 or 0.95) just to be safe. Interestingly, while we often talk about the effect of exceeding the explicit timestep, there are also issues with taking too small a timestep! Essentially, due to truncation and round-off errors as you decrease your timestep below the critical timestep you get closer and closer to solving (for solid-mechanics) a mass-spring system instead of a stress-wave propagation problem. So this is why you wouldn't want to choose a scale-factor of 0.01 or 0.001 for your stable timestep and then (probably) never have to recompute it.
Often within nonlinear static problems we use continuation methods (aka homotopy methods)to solve them. The general idea here is to solve the problem in a sequence where you "scale" the physics of the problem by some parameter, call it ε, at each iteration in the sequence. You use each solution to each scaled problem as the input to the next problem, with a slightly large value of ε. This ε is what codes like Abaqus call "Step Time" in their implicit static solvers. Furthermore, we often use this ε parameter as a "pseudo-time" quantity to "hack" time into our problem. For example we might model the manufacturing process of coiling a wire spring as a statics problem and use an implicit solver within a continuation method. The wire might have a temperature that we want to conduct and convect to the environmnet as well as plastically deform due to moving through space and contacting the tooling. The plasticity model might even be "rate-dependent". In such a case we might have ε vary from 0 to 2.5 and tell the solver to treat ε as time within the material, contact, and interaction models. As a sidenote, we can consider the explicit quasi-statics approach of the previous paragraph to be a continuation method.
Another important thing to mention is that we often use Newton's method to solve nonlinear implicit FEA problems. In Newtons method, we linearize the nonlinear system of equations and solve the linearized system. We then "plug" the linear solution back into the nonlinear equations, re-linearize, resolve... repeat until we converge. This linear solve portion is important to remember for later. There are other methods of solving these nonlinear problems such as nonlinear conjugate gradient (see Sandia's "Sierra/Solid-Mechanics" solver) or (more generally) Jacobian-free Newton-Krylov methods (see Idaho National Labs' "MOOSE" code).
So let's take a moment state the four categories of [tt]solver-problem[/tt] that we described above:
[ul]
[li]Explicit-Dynamic[/li]
[li]Explicit-(quasi)Static[/li]
[li]Implicit-Dynamic[/li]
[li]Implicit-(quasi)Static[/li]
[/ul]
There are some general rules of thumb that we can use to compare the cost of explicit and implicit solvers. (Imagine me giving the "rough handwavey" gesture throughout).
[ol 1]
[li]A single linear system solve in a Newton iteration is often at least ~100x as expensive as a single explict timestep. Newton's Method may require multiple iterations (i.e. multiple linear solves) to converge. And every time you relinearize, you have to update your element Jacobians / perform integration / reassemble... so in practice a single nonlinear solution may be 1000x (or more) as expensive as a single explicit solve.[/li]
[li]Even in a dynamics problem, there is still usually a "maximum physics frequency" that the engineer cares about which may be different than the "maximum frequency driving the problem". For instance, in the coiling of the wire spring, we could very-well model this as a dynamic problem. However, the engineer probably doesn't care about capturing physics that occur at super-high frequencies. They don't need to resolve the stress wave, just the averaged effect of stress. An explicit solver's critical timestep is often much smaller than the physics the engineer cares about. For example the stable timestep for the (explicit) coil problem might be 1e-10 seconds, which is capturing way more physics than the engineer actually needs. An implicit dynamic approach might give them a critical timestep of 1e-3 seconds and an implicit static approach might allow them to have Δε of ~5e-2 while achieving satisfactory results[/li]
[li]So why not always use implicit methods? The first is because sometimes the engineer does need to resolve very high-frequency physics to obtain good results. In a car-crash, for example, there are a lot of objects that are deforming rapidly and making contact with their closeby neighbors. And its this contact that is the principle driver behind their deformations, therefore nonlinear contact needs to be satisfactorily resolved, and thus a small timestep is required. Even if we were to solve this with implicit techniques, we would still need to advance at timesteps that can sufficiently resolve the contact... maybe only 1.5x-5x larger than the explicit timesteps. In these cases, it's simply faster to solve the problem using an explicit formulation![/li]
[li]Another reason to not use an implicit method is that a problem may have poor conditioning that causes the linear & nonlinear problems with converging. While my advice is that this should be a signal to improve your problem's conditioning (e.g. better mesh quality, change quadrature scheme, etc.) many engineers will switch to explicit because "it'll just solve". Often times, this is when the explicit-(quasi)static approach is used. They'll apply mass-scaling to bring the stable timestep up from 1e-10 seconds to maybe 1e-6 seconds which allows them to get a solution in a reasonable amount of time. Many times this explicit-(quasi)static approach "has" to be taken as improving the conditioning might be practically impossible. For instance, it might require increasing the mesh density so much that the problem is too larger for their computing resources. I've seen this IRL - a 10M element model needed ~250M elements to achieve good conditioning! We didn't have enough RAM on our 100-node HPC run this problem![/li]
[/ol]
To give some short answers:
>What would happen (stability/convergence/computational cost)if we use:
>1) large time steps for explicit approach
The simulation would abort pretty soon, since elements would collapse or invert itself.
>2) small time step for implicit approach
The computational cost (run time) would be higher than (numerically) required.
>What would happen (stability/convergence/computational cost)if we use:
>1) large time steps for explicit approach
The simulation would abort pretty soon, since elements would collapse or invert itself.
>2) small time step for implicit approach
The computational cost (run time) would be higher than (numerically) required.
- Thread starter
- #5
-
1
- #6
IceBreakerSours
Bioengineer
There is no concept of convergence if you are using an explicit scheme (i.e., there is nothing to converge to) because you are not solving a system of equations. All you do in an explicit simulation is, assume physics is correct at t=0, march through time with very small time steps, and hope that you are going to avoid non-physical solutions as the scheme is marching through time.
I ran into an academic code that didn't have an auto time stepper but, other than that exception, all commercial implicit codes I know of have auto time stepping schemes that do fine for a wide class of problems (especially the ones the code developers have run into). Every once in a while, expert analysts go in and tweak some of the knobs in special cases.
*********************************************************
Are you new to this forum? If so, please read these FAQs:
I ran into an academic code that didn't have an auto time stepper but, other than that exception, all commercial implicit codes I know of have auto time stepping schemes that do fine for a wide class of problems (especially the ones the code developers have run into). Every once in a while, expert analysts go in and tweak some of the knobs in special cases.
*********************************************************
Are you new to this forum? If so, please read these FAQs:
-
1
- #7
Hi
I "played" a bit with an academic code some years ago. If the timestep was to large the explicit solution it could explode as it became unstable. By "explode" I mean that the calculated deformations could become very large.
As for convergence in implicit analysis there are a lot of numerical "tricks" to make a solution converge. And the effeciency varies with the application. But often a reduced time step helps for implicit solutions also. To reduce the differences in the results between the computed time steps can help the convergence. At least that is my experience.
But using unnecessary small timesteps for implicit analyses does not improve the solution.
Thomas
I "played" a bit with an academic code some years ago. If the timestep was to large the explicit solution it could explode as it became unstable. By "explode" I mean that the calculated deformations could become very large.
As for convergence in implicit analysis there are a lot of numerical "tricks" to make a solution converge. And the effeciency varies with the application. But often a reduced time step helps for implicit solutions also. To reduce the differences in the results between the computed time steps can help the convergence. At least that is my experience.
But using unnecessary small timesteps for implicit analyses does not improve the solution.
Thomas
- Status
Similar threads
- Locked
- Question
- Question
- Locked
- Question
- Locked
- Question