OpenSWMM Engine  6.0.0-alpha.4
Data-oriented, plugin-extensible SWMM Engine (6.0.0-alpha.4)
Loading...
Searching...
No Matches
openswmm::fv::FvStepForcing Struct Reference

#include <INetworkSolver.hpp>

Collaboration diagram for openswmm::fv::FvStepForcing:

Public Attributes

const double * node_lateral = nullptr
 
const double * node_fixed_head = nullptr
 
const double * structure_flow = nullptr
 
const double * link_q_cap = nullptr
 
const double * conduit_loss = nullptr
 
void(* refresh )(void *user, double t_elapsed) = nullptr
 
void * refresh_user = nullptr
 
int n_nodes = 0
 
int n_links = 0
 

Detailed Description

Per-routing-step boundary forcing pushed into the solver before advance() and results pulled back after. Kept as a flat struct so the plugin ABI can pass it across the C boundary unchanged.

Member Data Documentation

◆ conduit_loss

const double* openswmm::fv::FvStepForcing::conduit_loss = nullptr

Distributed conduit loss rate per unit length (ft²/s, positive = loss) from evaporation and seepage. Indexed by conduit row.

◆ link_q_cap

const double* openswmm::fv::FvStepForcing::link_q_cap = nullptr

Upper bound on the pass-through discharge of each DUMMY link (cfs), indexed by link: the FLOW_LIMIT from [CONDUITS], or 0 when a control rule has closed the link. Negative means unlimited. Only DUMMY entries are read. Legacy applies both gates in the same order — setting first, then the limit (computeNonConduitFlowOne, HydStructures.cpp:1196-1212).

◆ n_links

int openswmm::fv::FvStepForcing::n_links = 0

◆ n_nodes

int openswmm::fv::FvStepForcing::n_nodes = 0

◆ node_fixed_head

const double* openswmm::fv::FvStepForcing::node_fixed_head = nullptr

Prescribed head at boundary-controlled nodes (ft, absolute elevation); NaN entries mean "not prescribed" and the node is advanced by its own continuity equation. Indexed by node. Outfalls arrive here.

◆ node_lateral

const double* openswmm::fv::FvStepForcing::node_lateral = nullptr

Lateral inflow at each node (cfs), as assembled by SWMMEngine::assembleLateralInflows. Indexed by node. May be nonzero at a kNodeVirtual node too: the in-tree solver splits it half/half into the two cells adjoining the node's spliced face (node_vj_face) as a zero-momentum area source, and a device backend must do the same — a virtual junction owns no faces, so any node-side integration of the value silently drops the water.

◆ refresh

void(* openswmm::fv::FvStepForcing::refresh) (void *user, double t_elapsed) = nullptr

Optional hook the solver calls at the start of each substep so head-dependent boundary flows can be re-evaluated against the state it has actually reached, rather than held at the value they had when the routing step began (FV_STRUCTURE_COUPLING SUBSTEP).

The callee is expected to refresh structure_flow and node_fixed_head in place. A raw function pointer, not a std::function: FvStepForcing has to stay trivially copyable so a device backend can take it by value.

It does NOT cross the plugin ABI — a device backend leaves it null and clamps to ROUTING_STEP, since the structure equations live in the engine, not the kernels.

◆ refresh_user

void* openswmm::fv::FvStepForcing::refresh_user = nullptr

◆ structure_flow

const double* openswmm::fv::FvStepForcing::structure_flow = nullptr

Non-conduit (pump/orifice/weir/outlet) link flows in cfs, signed positive from node1 to node2. Indexed by link; conduits are ignored.

DUMMY-xsect conduits are the exception: they are structure links (mesh.struct_is_dummy) but their discharge is not a head relation the engine can evaluate outside the solver — it is whatever arrives at the upstream node. The solver derives it from its own fluxes and ignores this array for them; link_q_cap carries the only thing it cannot know.


The documentation for this struct was generated from the following file: