Skip to content
GitLab
  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • B BasicDTUController
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 23
    • Issues 23
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 0
    • Merge requests 0
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • OpenLAC
  • BasicDTUController
  • Issues
  • #39
Closed
Open
Created Mar 22, 2019 by David Verelst@daveMaintainer0 of 3 tasks completed0/3 tasks

calling multiple times per time step

By default the HAWC2 type2_dll interface is used. This means there are no iterations between the controller/servo's and the aeroleastic solution of HAWC2. This can result in an underestimation of the damping of modes with a significant drive train torsional component. Especially the generator servo model should be part of a converged aero-servo-elastic solution, rather than an aeroelastic solution with a generator torque output on top of it.

@gepir has already made the necessary fixes in the master to allow for the controller and servo's to be called multiple times per time step (see MR !29 (merged)) . However, that still requires another HAWC2 dll interface. This interface should look, ideally, like a type2_dll but has an option to specify if it has to be called once or multiple times per time step. @anmh made a prototype for this, but it is not yet merged into HAWC2 master.

What this should NOT result in is that the controller can look into the future. In real systems the controller always lags one time step behind the system: a measurement signal is sampled, passed on to the controller, and a response is formulated. That response can only become available one sample later.

I suggest we use this issue to track that:

  • the basic principle is documented with an example (@dave and @gepir have the simulations)
  • HAWC2 gets an updated type2_dll interface that can be called multiple times per time step
  • the "call multiple times per time step" feature is added to the documentation and report
Assignee
Assign to
Time tracking