Hi, I’m using WEIS for the first time, and I would like to know if I have understood well enough the settings.
I’ve installed WEIS, run a few examples, and everything seems to work.
Now I would like to use WEIS to benchmark a stiff-stiff tower geometry, for the IEA 15MW Umaine SS.
In particular, I would like to double check the frequency of the tower mode of vibration with the lowest frequency, in the sense that it should be above a certain margin from 3P max.
What would be the most efficient way to do an eigenanalysis of the whole system?
Would the example in WEIS/examples/12_linearization/weis_driver.py do, extracting the tower 1st tower frequency from towerse.tower.f1? Or there is a better/quicker way?
The reason I ask is that, in the old days, I can run BModes, and get the frequency, without performing any linearization.
Many thanks
Hi Maurizio,
Thank you for your interest in WEIS and the time you’ve taken to already understand a great deal about the code.
The towerse.tower.f1 output is appropriate for a land-based turbine. The output you want is floatingse.fore_aft_freqs and floatingse.side_side_freqs. Those try to capture the correct boundary condition for a floating platform.
Behind the scenes, the modal frequency analysis is computed by the WISDEM code, a dependency of WEIS, which itself is calling Frame3DD via its python wrapper. Frame3DD is a general purpose 1-D structural finite element solver that is our replacement for BModes.
WISDEM (and Frame3DD) is always called by WEIS as the first analysis step and is independent of the OpenFAST or RAFT call. So, the floatingse.fore_aft_freqs output is available whether you are doing linearization in OpenFAST or not. You’ll find those outputs in the other examples in WEIS (such as this one) or even if you wanted to run WISDEM as a standalone code (floating example here).
The limitations of BModes would still apply to the WISDEM/Frame3DD approach to calculating the eigenfrequencies of the floating tower. It is a rigid body, static calculation. You may find that an OpenFAST “pluck test” or other type of modal testing with the full system and dynamics will give a more refined answer.
Cheers,
Garrett
Thanks a lot, @Garrett.Barter.
I think I understood - I run WEIS, specifying only WISDEM options in my modeling_options.yaml file, and in the output I can see floatingse.structural_frequencies, floatingse.fore_aft_freqs. floatingse.side_side_freqs , so I suppuse these are it?
I also wanted to double check some constraints, and I noticed that there is this WISDEM example for an offshore monopile. Can the same be done for a tower on a floating wind turbine, obtaining a similar graph? I’ve noticed that while in towerse there is the parameter towerse.post.constr_global_buckling, in floatingse there is the floatingse.constr_platform_global_buckling, but in the second I cannot see the values contained in the first. Is it because, even for the floating structure, I should read the values in towerse? Or should I look somewhere else?
By the way, thanks a lot for all the good work gone into WEIS, it’s amazing!
Hello Maurizio,
Thank you for the kind words.
Yes, the same advice would apply to the constraints as well. The towerse.* constraints are appropriate for a clamped tower (land-based). The floatingse.* constraints are more appropriate for your application. You mentioned you saw empty values? That shouldn’t be. I would double check you have the latest version of WISDEM (3.16.4).
Hi Garrett.
So, If I understood well, all the parameters with a towerse. root should not be read/used for a floating wind turbine?
I tired to remove all the towerse. branch from the modeling yaml, but WEIS seems to complain that it cannot find some values (See below). So, it is necessary to include, in the WISDEM modeling options, the TowerSE analysis, even if a floating wind turbine is being analysed?
It seems so, since looking at the file modeling_options_umaine_semi.yaml from example 06 here, there are specifications for the TowerSE,even if it should be the Umaine SS?
This is the error message I get if I remove the towerse. branch from the WISDEM in the modeling file:
'wisdem.wt' <class WT_RNTA>: Attempted to connect from 'drivese.rna_I_TT' to 'floatingse.rna_I', but 'floatingse.rna_I' doesn't exist. Perhaps you meant to connect to one of the following inputs: ['floatingse.turbine_I', 'floatingse.yaw', 'floatingse.turbine_M'].
'wisdem.wt' <class WT_RNTA>: Attempted to connect from 'drivese.rna_cm' to 'floatingse.rna_cg', but 'floatingse.rna_cg' doesn't exist. Perhaps you meant to connect to one of the following inputs: ['floatingse.turbine_cg', 'floatingse.Uc', 'floatingse.yaw'].
'wisdem.wt' <class WT_RNTA>: Attempted to connect from 'drivese.rna_mass' to 'floatingse.rna_mass', but 'floatingse.rna_mass' doesn't exist. Perhaps you meant to connect to one of the following inputs: ['floatingse.turbine_mass', 'floatingse.anchor_mass', 'floatingse.rho_mat'].
Hi Maurizio,
When grabbing outputs to use for your own purposes, you should look to the floatingse.* outputs. However, the TowerSE module is very much still needed in WISDEM for many internal calculations. It also holds the tower geometry in its data structure for all applications. You should not need to be editing any entries in the main glue code (which is what it sounds like you have done).
Many thanks, Garrett - makes sense.
As far as I know, I should have not modified (at least intentionally) any python script in the modules, only modifying the modeling and analysis options yaml files. I also checked with conda list wisdem, and the wisdem version is 3.16.4.
Sorry, I probably should have been clearer.
If I only run WISDEM, I can see the natural frequencies (with all the limitations of an eigenanalysis) and modes of vibrations in the output file (floatingse.structural_frequencies). I suppose that since the floating substructure itself is rigid, these are the first 3 fore_aft and first 3 side_side modes natural frequencies.
I’ve also grabbed floatingse.constr_platform_shell_buckling and floatingse.constr_platform_global_buckling, the shell buckling and global buckling checks (if I understood well), but these are 500x1 vectors. My question is: I suppose 10 elements out of these 500 are global and shell buckling utilisation ratios for the tower (since the tower should consist of 10 cylindrical elements), but how to know which ten values are those relative to the tower elements?
Hi Maurizio,
You are now arriving at a known gap or shortcoming in WISDEM for floating analysis.
While the modal analysis can be done statically, determining floating loads and then doing the buckling analysis is awfully difficult to do in a steady-state code. I would not rely on the floatingse.constr_*_buckling to do your structural design (the tower is also not included in those outputs). For that, we recommend leveraging WEIS and doing a frequency-domain analysis in RAFT or a time-domain analysis with OpenFAST. However, even if you go that route, there are capability gaps as I don’t know if the connection between those more accurate load calculations and the follow-up tower buckling analysis has been fully tested and vetted for floating platforms. It should work, but I would recommend you verify with some of your own hand-done post-processing. Closing these gap is on our development roadmap
Many thanks, @Garrett.Barter , very appreciated.
Basically, if I understood well:
- the
floatingse.constr_*_buckling are not including any buckling analysis results of the tower, but only of the floating substructure elements
- the
towerse.post.constr_*_buckling are not relevant when analysing a floating wind turbine, so should be ignored
- it may be possible by enabling a RAFT or OpenFAST in WEIS to obtain the values necessary for checking local/global buckling on the tower, but these have not been fully tested yet.
The question is then: if I run RAFT or OpenFAST, then how I enable the checking of local/global buckling on the tower, and where I can read the results of those checks?
Many thanks for the patience!
Hi Maurizio,
Yes, you have it right. If you run OpenFAST, you will see outputs in WEIS labelled towerse_post.constr_shell_buckling. That is what you want. I might have overstated earlier in saying this would be available with RAFT too. It looks like only OpenFAST.
Many thanks @Garrett.Barter, clear and understood!
Sot he towerse.post.constr_*_buckling are not relevant, but if OpenFAST is run then towerse_post.constr_*_buckling are the one I need for a tower on a floating wind turbine.