-
Notifications
You must be signed in to change notification settings - Fork 465
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
Bug report: Cholesky error in TurbSim API turbulence model #386
Comments
So how could we eliminate that error from happening again? Since most turbulence cases require high wind speeds |
Are you having an issue with a particular model? I believe "high" is somewhat relative here, and it's usually a combination of things that cause the coherence matrix to not be positive definite. |
I implemented my own approximation to avoid (not fully solve) this problem. On TSsubs.f90, subroutine CalcFourierCoeffs_API, I added a previous loop over the frequencies to find the minimum frequency for which the coherence matrix was positive definite. Then, on the original loop, I imposed the frequencies to be equal or larger than this minimum frequency. This introduces some error for the low frequency coherence matrices, but the code works, and, since the really low frequencies do not have an important role in the wind spectrum, the introduced error should not be significative. I also printed the minimum frequency to check that it was in fact among the smaller frequencies. Find the modified function below (see the new loop below comment line "! Compute minumum allowed freq" and note the use of the new variable min_freq), hope this helps!
|
Despite amending those "! Compute minimum allowed freq" in TSsubs.f90, the same Cholesky factorization: LAPACK_SPPTRF error has been announced. Even with some changes in WindProfileType (PL/API) and Spatial Coherence Parameters (SCMod1), it still gives the same output. Is there any way to get around this issue? Here is an example input file that will replicate the error message: `--------TurbSim v2 (OpenFAST) Input File------------------ --------Turbine/Model Specifications----------------------- --------Meteorological Boundary Conditions------------------- --------Non-IEC Meteorological Boundary Conditions------------ --------Spatial Coherence Parameters---------------------------- --------Coherent Turbulence Scaling Parameters------------------- [used only when WrACT=TRUE] ==================================================== |
@mhank, you can try to decrease the number of points in your grid. You have a pretty small grid spacing, so you could probably try 29 instead of 41 points for |
@bjonkman , Instead of 29 points, I managed to run the script when both |
Whether or not that coherence matrix (see the equation in the first comment of this issue) is positive definite depends on a combination of different things: wind speed, grid spacing in Y and Z directions, frequency (AnalysisTime and time step), and height. At each frequency a coherence matrix is formed and the Cholesky factorization is performed on that matrix. If the matrix is not positive definite, that factorization will fail. Generally, it means that there is "too much" coherence (too many values close to 1) in the matrix. There are methods in literature that will help you find the closest positive-definite matrix to a matrix that is not positive definite; it is possible that the API model needs this. When you ran the code that @arodriguezluis shared, what frequency did it say was the minimum it was using? And what frequency is it failing at with 29 points? |
Dear@bjonkman |
Appendix B in the TurbSim User's guide has some tips for setting up TurbSim grids: https://github.com/OpenFAST/openfast/blob/main/docs/OtherSupporting/TurbSim/TurbSim_v2.00.pdf For large rotors, we typically recommend about 5-m grid resolution. |
Dear@bjonkman |
Dear @icnosvbovwb, There are grid points at the boundaries of the domain, so you must add one to your calculations, e.g. 175/5+1 = 36. But a grid size of 200-m width by 175-m high seems excessively large for the NREL 5-MW wind turbine with a rotor diameter of 126 m for an OpenFAST-only simulation (FAST.Farm requires larger domains). Normally the grid need not be more than 10% larger than the rotor diameter unless you are expecting excessive motion, e.g., in floating wind applications. Our typical rule of them is to define the spatial resolution of the turbulence box to be on the order of max chord, which for the DTU 10-MW turbine is about 6 m. Best regards, |
Dear @jjonkman |
Dear @icnosvbovwb, The TurbSim grid must encompass the tower if aerodynamic analysis nodes are enabled along the tower in the AeroDyn module of OpenFAST. You can extend the domain in TurbSim downwards by changing the Best regards, |
Dear @jjonkman |
Bug description
The bug found is in relation with the Cholesky error that sometimes is displayed when we run the API model on the TurbSim:
CalcFourierCoeffs:CalcFourierCoeffs_API: Error in Cholesky factorization: LAPACK_SPPTRF: Leading minor order 21 of A is not positive definite, so Cholesky factorization could not be completed. The error occurred in the u-component coherence matrix at frequency 1 (2.63158E-04 Hz). Check the input file for invalid physical properties or modify the coherence. Aborting TurbSim.
We have been doing some tests and it looks like the error comes out when the Coh matrix (shown in the expression below) is big in size and it has many elements close to 1.
This happens specially when:
We found that the reason for the first three points above returning an error is that when the “LAPACK_SPPTRF” subroutine computes the determinant of the matrix, it is below the machine precision (although it should not be zero). This is because all elements are close to one.
We believe that this error may also appear in other models if the spatial coherence matrix is built in a similar way (https://wind.nrel.gov/forum/wind/viewtopic.php?f=4&t=1766).
To reproduce the bug:
Our compilation on linux was based on the file 'compiling/makefile' found individual TurbSim repository (https://github.com/old-NWTC/TurbSim), but we used the latest openFAST Turbsim module source code instead. To get the error, for example, run a case with input: TurbSim.zip
The text was updated successfully, but these errors were encountered: