WEIS: how to setup a single OpenFAST run of a geometry generated by WEIS/WISDEM

Hi,
I’ve consulted the WEIS documentation, but I am going around in circles.
Can you point me to the most relevant example, among the WEIS examples (or maybe a combination of them), to do the following?

  1. After creating a new geometry yaml file for a different tower geometry for the IEA 15MW UMaine semisub (I understood how to do it), generate the PpenFAST input files for this modified configuration
  2. Run a simple OpenFAST simulaiton, with constant wind speed, PLExp = 0.12, no turbulence, no waves, no currents, at rated wind speed
  3. I think I know how to read the outb file and where this is, to then extract the final average platform tilt angle. It’s mainly step 1 and 2 I am a bit confused about.

Initially I thought it is something along the lines of examples/02_run_openfast_cases, but in the README.rd file it explicitly says that “These examples run an OpenFAST model that has not been generated by WISDEM”

Many thanks for the help

Hi Maurizio,

WEIS examples 03, 04, 05, and 06 all use a yaml file to generate an OpenFAST model. To accomplish what you want, I suggest:

  • Grab a python driver file from the examples and edit it to point to your geometry yaml file with the customized tower geometry
  • Suppress optimization in the analysis options file
  • Set the OpenFAST InflowWind options in your modeling options file to get your designed uniform flow properties. This draft upgrade to the docs will probably help.

Apologies if I have oversimplified your question by skipping steps. Feel free to follow up.

Cheers,
Garrett

Thanks, @Garrett.Barter.
I started from example 06, and I have a few questions.

  1. When using weis_driver_umaine_semi.py , and therefore modeling_options.yaml, why the following modeling options is true, if it is for a floating wind turbine?
FixedBottomSE:
        flag: True
        soil_springs: True
  1. When running this weis_drivey_umaine_semi.py, I encounter the following error:
  File "C:\Users\mauri\miniforge3\envs\weis-env\Lib\site-packages\openfast_io\FAST_writer.py", line 2361, in write_MoorDyn
    ln.append('|'.join([float_default_out(a, trim=True) for a in self.fst_vt['MoorDyn']['EA'][i]]))
                                                                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^
TypeError: 'aeroelastic' <class FASTLoadCases>: Error calling compute(), 'numpy.float64' object is not iterable

The files I’m using are the same as in the github repository example 06

Any clue?

Hi Maurizio,

You are correct about the modeling_options file. That is a copy and paste error and only confuses things. Even though the FixedBottomSE flag is True, within the code, if there is no monopile or jacket section found in the geometry yaml, then the flag is reset to False, so the case still runs just fine. I agree that for an example, this type of confusion should be avoided.

The next release of WEIS will re-organize the examples to be more representative of a user case, instead of just the turbine that is used. You can preview the new slate of examples here. I see the copy-paste error persists there too and will fix it.

For the error, I believe Dan Zalkind has addressed it in the repo Issues here.

HI @Garrett.Barter ,
I tried to:

but:

  1. I specified my InflowWind options in the modeling yaml (under OpenFAST), and block commented the DLC_driver block.
penFAST: # Options for WEIS fidelity level 3 = nonlinear time domain
    flag: True
    simulation:
        DT: 0.01
        CompElast: 1
        CompInflow: 1
        CompAero: 2
        CompServo: 1
        CompHydro: 1
        CompSub: 0
        CompMooring: 3
        CompIce: 0
        OutFileFmt: 3
        NumCrctn: 1
    linearization:
        Linearize: False
    InflowWind:
        Echo: True
        WindType: 1
        HWindSpeed: 10.64
        PropagationDir: 0.0
        RefHt: 150.0
        PLExp: 0.12

Nonetheless, Weis takes by default DLC 1.1, and runs that, not my InflowWind conditions.
2) I tried, then, to specifically put DLC1.1 with the desired wind speed, and specifying:

DLC_driver:
    DLCs:
        - DLC: "1.1"
          analysis_time: 60
          transient_time: 0
          turbulent_wind:
            flag: False
            HubHt: 150
            WindProfileType: 'PL'
            RefHt: 150
            PLExp: 0.12

But, still, checking the simulation performed, it still generates a turbulent wind speed, not a steady wind speed as I thought.

Let me know if you spot the mistake

Thanks

Typical! The moment I posted the above, after trying many things, I then tried something else and it worked.
It seems that the way to impose a steady wind that works is the following:

  1. InflowWind settings in the OpenFAST section seems to be overwritten or not considered, BUT, curiosly, I was able to set the “no waves” conditions through:
OpenFAST:
    SeaState:
        WaveMod: 0
  1. The following works, i.e., setting TurbModel to ‘NONE’
DLC_driver:
    DLCs:
        - DLC: "1.1"
          wind_speed: [10.64]
          analysis_time: 60
          transient_time: 0
          turbulent_wind:
            flag: True
            HubHt: 150
            WindProfileType: 'PL'
            RefHt: 150
            PLExp: 0.12
            TurbModel: 'NONE'

Hi @Garrett.Barter, another questions - apologies, still getting my head around how weis is organised.
I am using the example 06 weis_driver_umaine_semi.py, since I would like WISDEM/WEIS to create the OpenFAST model from the yaml files, and then launch the OpenFAST simulation.
Is there a way to force WISDEM/WEIS to adopt a given ROSCO controller, rather than redefining a Cp_Ct_Cq.txt file and tune the ROSCO controller? I tried many things, but none works.

I came across the option

OpenFAST: 
    flag: True
    from_openfast: True

but I suppose that if ‘from_openfast’ is True, then wisdem is not taken into account at all.

Many thanks

Hi Maurizio,

Apologies for the delay in responding to this one. I better understand your issue now and apologies that it wasn’t clear to me in the beginning.

Running a simple, steady, uniform flow was supported by WEIS initially, but in the DLC driver overhaul is temporarily absent. There is a PR to restore it. There are still a few kinks to work out before it is merged. Essentially, you will set a DLC: "Steady".

In the interim, you can take the OpenFAST files generated by WEIS for another DLC, such as 1.1, and then modify the InflowWind file and run OpenFAST by hand (outside of WEIS). I know this route is ideal, so hopefully the PR will be complete soon.

For your ROSCO question, I will ask Dan Zalkind to help answer.

Cheers,
Garrett

Hi Maurizio,

You can specify a ROSCO tuning yaml like this: WEIS/examples/06_IEA-15-240-RWT/modeling_options_umaine_semi.yaml at b9d9d6ee8314530bef542e9b84d79696ccb50a69 · WISDEM/WEIS · GitHub. This will specify the ROSCO controller based on the tuning yaml parameters.

You could also use the generated OpenFAST model, then the from_openfast flag like you suggest, but WEIS will still use the tuning yaml to generate a DISCON from the model and Cp surface.

If you’re asking for how to assign a DISCON directly as an input, and skip the ROSCO tuning procedure, that is not currently a feature, but it’s something I have done recently on a feature branch for the EAB case studies and another project. If this is what you’re looking for, I could streamline its integration and get it into the main code base in the next week or so.

Please let me know what you’re looking for when you mean “a given ROSCO controller” and we’ll figure out how to get you going.

Best, Dan

Thanks a lot, @Garrett.Barter , looking forward to the new version with the “Steady” case.

Thanks, @Daniel.Zalkind .
I would like to be able to launch some OpenFAST simulations with WEIS, where some of the components of the wind turbine are changed, but the control system remain unchanged - i.e. there is no tuning whatsoever, and an existing Cp_Ct_Cq table is used.
Basically, it all comes from the fact that, in some projects, I am allowed to change the characteristics of one component (tower), but not the control system.

If you can merge into the main repository that would be fantastic.

Thanks a lot, Maurizio