Synchronous UCS Map

[atbrandao]

ROSS currently considers no gyroscopic effects for the plot_ucs() method, as it calls run_modal(speed=0).

The UCS Map should considers synchronous eigenvalues. That is to say that each plotted natural frequency considers the gyroscopic effects of the rotor at for speed = frequency.

This can be achieved by iterating eigenvalues, however this strategy would be very time consuming.
XLTRC2 uses a transformation of the M matrix that constrains the rotor speed to the eigenvalue frequency, simplifying this calculation.
I extracted the paragraph below from XLTRC2 Help File:

An undamped critical speed analysis is a special type of eigenvalue calculation. All bearings are reduced to simple undamped axisymmetric springs such that Kxx=Kyy and Kxy=Kyx=0 (see Brg's Worksheet). Also, the rotor transverse inertia, It, is replaced with the transverse minus the polar inertia (It-Ip). This last modification, in effect, constrains the rotor rotational speed to equal the eigenvalue frequency. This means that computed eigenvalues are automatically synchronous (i.e., whirl frequency = rotor speed). Recall that eigenvalue frequencies normally vary with rotor speed because of gyroscopics. At particular values of rotor speed where the frequency of a forward whirling eigenvalue matches exactly the speed, the eigenvalue is termed a synchronous critical speed. This special command computes such eigenvalues directly, without the need to iterate the rotor speed.

Would it be possible to implement this transformation on ROSS?

[raphaeltimbo]

I will start to implement this.
Some other points that I have noticed that maybe we will need to change:

• The undamped critical speed analysis is not a run_ method, and I think this goes against our design. Maybe we should change this?;
• Should we change the name ucs to undamped_critical_speed_analysis? It has the con of being a long name, but is more helpful for those that are not used to use the name ucs. What do you guys think?;
• Another point is that the user does not have an option of choosing how many modes he can evaluate when calling the function. This goes back to a design that we used in the beginning of the project where some of this arguments would be defined as rotor attributes. Take for example a case where the user wants to determine the natural frequencies:

rotor.n_eigen = 8    # define number of modes
rotor.speed = 1000   # define the speed and run eig()
rotor.wn             # get the frequencies

Now we have something like:

rotor.n_eigen = 8
modal = rotor.run_modal(speed=1000)
modal.wn

I think we should evaluate if this makes more sense:

modal = rotor.run_modal(speed=1000, n_eigen=8)
modal.wn

I think this has the advantage of being more explicit (just like when we changed the speed to be an argument of run_modal()).
What do you guys think?

@atbrandao , @rodrigomoliveira1

[rodrigomoliveira1]

It makes sense. I'd feel more confortable passing the n_eigen argument to the .run_modal() method than setting it as rotor attribute.

[atbrandao]

Going through it point by point:

• From the user perspective I don't know if running the UCS as a ´run_´ method would be the best option, because it is not actually an analysis, like the other ´run_´ methods, it is actully just a plot. Maybe we could change it to ´.plot_ucs()´, or ´.plot_ucs_map()´. The only relevant result coming from the UCS is the plot, and if I want any other undamped analysis for my model, like undamped mode shapes, I would use ´.run_modal()´.

• I agree that using something more descriptive like ´.undamped_critical_speeds_map()´ would be a good idea for user friendliness. However, being the lazy user I am, I would like to still have a compact ´plot_ucs()´ option. Maybe a new method could be created only calling the other one?

• I fully agree that ´.n_eigen´ should be an argument for the applicable methods and not a ´Rotor´ attribute.

[raphaeltimbo]

Going through it point by point:

• From the user perspective I don't know if running the UCS as a ´run_´ method would be the best option, because it is not actually an analysis, like the other ´run_´ methods, it is actully just a plot. Maybe we could change it to ´.plot_ucs()´, or ´.plot_ucs_map()´. The only relevant result coming from the UCS is the plot, and if I want any other undamped analysis for my model, like undamped mode shapes, I would use ´.run_modal()´.

That is a good point. The problem is that we have added the Campbell diagram as a run_ method, so I am worried that we are not being consistent. But I think we can leave as it is now and see if other users will have trouble with this.

• I agree that using something more descriptive like ´.undamped_critical_speeds_map()´ would be a good idea for user friendliness. However, being the lazy user I am, I would like to still have a compact ´plot_ucs()´ option. Maybe a new method could be created only calling the other one?

Yes, typing this would not be nice. I was not thinking about that because I am always relying on some autocomplete tool, but it is a good point. Having two methods I don’t think it is a good idea since it could bring some confusion.

• I fully agree that ´.n_eigen´ should be an argument for the applicable methods and not a ´Rotor´ attribute.

I think this point is the one where we all agree, so I am going to start by implementing this and the required issue feature.

[raphaeltimbo]

I have implemented the synchronous calculation following this procedure:

1. Run modal analysis with speed=0;
2. Get frequency of first forward mode;
3. Run modal analysis with speed=<frequency from step 2>.

I have compared this method with the speed=0.
These are the natural frequencies for 20 points in the first forward mode:

speed=0	speed=first forw.
89.61923495560965	89.61946776560761
120.8965544124148	120.8974158658818
162.5924636808063	162.5960376028161
217.4255339621071	217.4409598699732
287.6459641822536	287.7123155000834
372.9354036898083	373.2068156469886
466.2582836676713	467.2244997732644
551.4079067107739	554.0120171948969
613.1241511391027	618.0232877804480
650.4695078673341	657.3825131548623
671.2485702990565	679.5056521508502
682.5360011963281	691.5888533048600
688.6492347723974	698.1515285102745
691.9661291495472	701.7175103146761
693.7694751245434	703.6577888407243
694.7513306253416	704.7146391141554
695.2863823982286	705.2906880198269
695.5781004710195	705.6047966404822
695.7371945881359	705.7761132397700
695.8239733024785	705.8695621453434

As expected, a have a larger difference in higher frequencies because of the gyroscopic effect.

The time to run the speed=0 method:
10.3 s ± 1.03 s per loop (mean ± std. dev. of 7 runs, 1 loop each)

The time to run synchronous=True method:
42.7 s ± 3.24 s per loop (mean ± std. dev. of 7 runs, 1 loop each)

Regarding this method:

Also, the rotor transverse inertia, It, is replaced with the transverse minus the polar inertia (It-Ip). This last modification, in effect, constrains the rotor rotational speed to equal the eigenvalue frequency.

For the disks it is easy to do this, but I could not figure it out how to change the mass matrice for the shaft elements considering this.

[raphaeltimbo]

We have merged the code mentioned in the comment above here #579.
Still investigating the It-Ip method.

[ross-bott]

Hi there!
I have marked this issue as stale because it has not had activity for 45 days.
Consider the following options:

• If the issue refers to a large task, break it in smaller issues that can be solved in
  less than 45 days;
• Label the issue as wontfix or wontfix for now and close it.

[fernandarossi]

Hi guys. I was searching for papers that discussed how to add the shaft gyroscopic effect into the UCS analysis of the rotor, and I found the follow doctorate thesis that seems to discuss the subject: Rouch, K. E., “Finite Element Analysis of Rotor-Bearing Systems with Matrix Reduction”, PhD Thesis, Marquette University, 1977. However, I can’t download it because the access is restricted. So, I am searching for other references that may help me with the numerical implementation.

[raphaeltimbo]

Thank you @fernandarossi.
Just to explain a little bit more about this issue here and why it is still open.
The results for the undamped critical speed analysis can be visualized in the following plot:

This plot is built following these steps:

1. Define a stiffness range in which the analysis will be carried out (in this plot 10^6 to 10^11) and divide this range in points (e.g. 100 stiffness values);
2. Go through each stiffness value replacing the bearings in the model with a bearing with fixed stiffness equal to the value from the range;
3. Calculate the eigenvalues with speed=0 for that model;
4. Iterate with a new speed until the speed is equal to the first natural frequency (synchronous case).
   This iteration to get the first natural frequency to be equal to the speed can consume some time. The idea presented by Brandão would decrease this time since the natural frequency would automatically be equal to the speed according to this explanation:

Also, the rotor transverse inertia, It, is replaced with the transverse minus the polar inertia (It-Ip). This last modification, in effect, constrains the rotor rotational speed to equal the eigenvalue frequency. This means that computed eigenvalues are automatically synchronous (i.e., whirl frequency = rotor speed).

This part has been not yet implemented and is the reason why this issue is still open.