Lin: CalcSteady, forcing linearization at end of simulation #958
Conversation
| @@ -5346,6 +5351,12 @@ SUBROUTINE FAST_CalcSteady( n_t_global, t_global, p_FAST, y_FAST, m_FAST, ED, BD | |||
| m_FAST%Lin%AzimIndx = 1 | |||
| m_FAST%Lin%CopyOP_CtrlCode = MESH_UPDATECOPY | |||
| end if | |||
| ! Forcing linearization if time is close to tmax | |||
| if ((t_global> p_FAST%TMax - 1.5*TwoPi_D/ED%y%RotSpeed) .and. .not.m_FAST%Lin%FoundSteady) then | |||
There was a problem hiding this comment.
Where does the 1.5 come from? And I'm concerned that if the rotor speed is varying a lot during the trim solution, this condition may be met before the tail end of a simulation. It would probably be better to use the initial rotor speed, which is the target rotor speed.
There was a problem hiding this comment.
I now replaced it with the Init rotor speed (this was a quick hack at first).
I do need a margin, and it seems that the margin is actually 2 revolutions. The problem is that the condition is triggered right after the first target azimuth, it then has to wait until the next target azimuth is reached (which takes one revolution), and then perform the saving of operating points (over one revolution). This is not ideal, but should be fine before we have a steady-state solve.
| if ((t_global> p_FAST%TMax - 1.5*TwoPi_D/ED%y%RotSpeed) .and. .not.m_FAST%Lin%FoundSteady) then | ||
| call WrScr('') | ||
| call WrScr('[WARNING] Steady state not found before end of simulation. Forcing linearization') | ||
| m_FAST%Lin%ForceLin = .True. |
There was a problem hiding this comment.
Should you also warn that the linearized model may not be sufficiently representative of the solution in steady state?
There was a problem hiding this comment.
I've now added a final warning at the end of the simulation.
|
I've added some conditions so that the forced linearization occurs in "reasonable" circumstances, to avoid misusages. It should also work for a 0 rotational speed. |
There was a problem hiding this comment.
Given that a steady-state solution was never found, I would suggest simplifying the linearization by only forcing one linearization at the end of the simulation (as if, NLinTimes = 1 with LinTimes = TMax, rather than trying to linearize about a full rotor revolution). This would simplify the logic and given that the linearized matrices may not be representative anyway, it probably doesn't matter that a full periodic set of linearized matrices was not generated.
|
Doing only one linearization makes sense (I need to change lintime to 1). It will also be easy for the user to notice since less lin files are present. I've made the change now. |
This pull request is ready to be merged
Feature or improvement description
Perform linearization at end of simulation if no steady state is found. Only one linearization is done at the final time step.
Impacted areas of the software
OpenFAST-library / linearization
Additional supporting information
At times, the trim algorithm does not find a steady state. This might indicate an issue in the model or in the algorithm itself. It is yet slightly unfortunate if no linearization occurs even if the user specify a large TMax.
A warning is displayed and it's the user responsibility to check that the linearization occur at a somehow close to periodic steady state.