Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • airGR airGR
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 60
    • Issues 60
    • List
    • Boards
    • Service Desk
    • Milestones
  • Redmine
    • Redmine
  • Merge requests 7
    • Merge requests 7
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • HYCAR-Hydro
  • airGRairGR
  • Issues
  • #104

Closed
Open
Created Mar 02, 2021 by Dorchies David@david.dorchiesDeveloper

RunModel_Lag: `StateEnd` is wrong if upstream flow is in mm / time step

In the lag model upstream flows related to a sub-basin are converted from mm / time step to m3 / time step. Initial states and upstream flows are merged in order to have the memory of the upstream flows before the simulation period but no conversion is applied to initial states.

So the initial states should either be converted if they are stored in mm/ts or stored in m3/ts.

There are pro and cons for the 2 solutions:

  1. store states in mm / ts and converted in simulation: Qupstream is already in mm/ts so it seems consistent to store the corresponding initial state (which is Qupstream before the simulation period) in the same unity.
  2. store states in m3/ts and use it directly in simulation which can avoid a computation burden due to a conversion at each run.

Concerning the second solution, maybe it could be a good idea to also convert Qupstream in m3/ts in CreateInputsModel in order to avoid an "on-the-fly" conversion at each run of RunModel_Lag. So, all upstream flows (States + Qupstream) would be in m3/ts and no computation burden would occur due to conversion.

Edited Mar 02, 2021 by Dorchies David
Assignee
Assign to
Time tracking