-
Notifications
You must be signed in to change notification settings - Fork 105
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Incorporate time integration to account for speed variations #1021
Comments
I tested a simple case to compare the numerical integration considering the representation of the model in both spaces. For the modal space, just the first 12 modes were considered in order to obtain the reduced model. For both spaces, the “RK45” integration method was considered. This test case is the same example described in # Rotor without damping with 6 shaft elements, 2 disks and 2 bearings
rotor = rotor_example()
speed = 500.0
size = 1000
node = 3
probe1 = (3, 0)
t = np.linspace(0, 10, size)
F = np.zeros((size, rotor.ndof))
F[:, 4 * node] = 10 * np.cos(2 * t)
F[:, 4 * node + 1] = 10 * np.sin(2 * t)
response = rotor.run_time_response(speed, F, t)
fig1 = response.plot_1d(probe=[probe1]) Running the code with time integration in the physical space took a total of 129 s, while in the modal space it took a total of 5.71 s. Therefore, considering the reduced model it was possible to reduce ~96% of the execution time. The responses for node 3 are compared and presented below: The response obtained by integrating in modal space seems to be very close to the response obtained by In terms of computational cost, I think it would be better to implement the integration solver in modal space. The idea would be to use a single solver for Rotor and Defect classes. @raphaeltimbo, any suggestions for additional testing? Which direction should I take with the implementations? |
Hi @jguarato ! |
@raphaeltimbo, you are right. I increased the time array and the results for the ‘physical space’ diverged using the RK45 integration method. I found the following article that may explain what happened in this case: Stability of Numerical Integration Techniques for Transient Rotor Dynamics. The author analyzed the numerical stability of some integration techniques, including the Runge-Kutta method, applied to transient rotor dynamics. One of the author's conclusions was that the high frequency mode usually determines the maximum time step for a stable solution. Therefore, considering an undamped system, the Runge-Kutta method is unstable for a time step greater than approximately: where Consequently, calculating for the problem at hand, this method is unstable for In this sense, an implicit method such as BDF ends up being more suitable for this case, for which it is possible to use a larger time step to obtain a stable solution: We can then compare these solutions with the results of the In the case of solving the equations in modal space, as the reduced model was considered based on the first 12 modes, it was possible to obtain a stable solution for a larger time step. Therefore, solving the equations in modal space with RK45 and without reducing the model also leads to an unstable solution, as can be seen below: |
To implement the newmark integration:
|
Hi there!
|
Discussions ensued regarding the previously acquired results, leading to the decision to adopt the Newmark method over the Scipy integrator. The new implementations have been incorporated into the PR #1032. The results of the tests conducted to validate the implementations can also be found in the comments of the PR. |
This issue was created in order to document and detail the task of implementing the numerical integrator that was assigned to me. This task may resolve other issues: #429, #884, #1001.
Currently, it is not possible to solve the transient model with the rotor speed varying over time in ROSS, nor to incorporate other information into the model that depends on time. One solution would be to use a numerical integrator to solve the following equation of motion for a rotor:
The function
solve_ivp()
available in SciPy integrate library can be applied in this case. This function numerically integrates a set of first-order vector ordinary differential equations (ODEs):given the initial conditions$\mathbf{y}(0)=y_0$ , and it also offers 6 different integration methods. Then, it would be possible to choose a more appropriate method for each type of problem, allowing to solve, for example, non-stiff problems using explicit methods (“RK23”, “RK45”, “DOP385”), and also stiff problems using implicit methods (“Radau”, “BDF”).
A higher-order ODE can be reduced to a first-order differential equation by introducing intermediate derivatives into the$\mathbf{y}$ vector. So, this implies that:
and accordingly$\mathrm{f}(t,\ \mathbf{y})$ must return:
where the second-order derivative could be calculated from the equation of motion by inverting the$M$ matrix as:
The values of rotational speed$\Omega(t)$ and acceleration $\dot{\Omega}(t)$ varying over time can be stored in arrays. Such arrays must be compatible with the array of times in which the computed solution will be stored.
Consequently, the integration can be done by calling:
and passing the callable function that will be integrated
fun(t, y)
, the interval of integrationt_span=[t0, tf]
and the initial statey0
. It is optional, but it could be important to pass the integration method, the vector of times in which the computed solution will be storedt_eval
, and a tuple of additional arguments that could be passed tofun(t, y, *args)
.At first, I defined the function
fun(t, y, *args)
to be integrated as follows:Here, I would like to highlight two points:
speed[i]
at a specific timet
can be done by a conversion based on the initial timet0
and time stepdt
to obtain the respective array index.When choosing to solve in the modal space, there is a possibility to reduce model based on the selected number of modes. A reduced model implies a considerable reduction in computational cost. Another option, suggested by Prof. Aldemir, to obtain the reduced model would be to pass the frequency range of interest.
The text was updated successfully, but these errors were encountered: