HydraLink Integration

HydraStorm's companion application HydraLink provides stormwater hydrology modeling including rainfall-runoff analysis, detention pond design, and culvert analysis. Import HydraLink results directly into HydraStorm to drive your storm drain hydraulic design.

Supported File Types

Extension	Description	Contents
.hyd	HydraLink native project file	Basins, junctions, ponds, storm events, full model definition
.hlresults	Pre-computed results export	Peak flows, outflows, volumes, stages

HydraStorm reads HydraLink exports through the current format (1.10) and remains compatible with exports from earlier HydraLink versions. Compatibility is checked by major version only, so a minor-version bump like 1.10 (ten, not "one-point-one-zero") can never be mistaken for a newer, incompatible format.

Setup

1. Set the hydrology mode to HydraLink in Project Settings > Hydrology.
2. Browse to the .hyd or .hlresults file using the file picker.
3. Select a Plan if the .hyd file contains multiple plans.
4. Select the Design Storm and optionally a Check Storm.
5. Click Import Flows to match basins to structures and pull in the file's published flows. Linked to a .hyd project file (which carries no published flows) the same button reads Compute Flows instead.

Import Basis

A HydraLink link can supply two different things, and they are mutually exclusive. Choose between them with the Import Basis radio pair in the HydraLink Integration block of Project Settings > Hydrology:

This page calls the second one Peak Flows, matching the radio label. Some calculation warnings and prompts still call it Fixed Flows — the same basis, the older internal name.

Basis	What the link supplies	How Q is computed
Basin Parameters (C·A·Tc)	Drainage area, runoff coefficient C, and Tc per matched structure, plus the IDF data	HydraStorm runs its own rational accumulation: Q = Cf × ΣCA × I, with Tc accumulated along the drawn pipe network. Imported peak flows do not enter it.
Peak Flows (HydraLink's flows)	HydraLink's published peak flows, including routed pond outflows where the model has them	The imported flows drive the network directly and accumulate downstream. No rational accumulation runs, and no IDF data is required.

When the choice is made for you

The linked file decides the basis whenever only one of them is defensible; the radios lock and a line beneath them explains why:

• The routed model contains ponds → Peak Flows is forced. A pond attenuates flow, and no basin-parameter accumulation can reproduce a routed outflow, so only the solved numbers are valid downstream of storage.
• The link is a .hyd project file → Basin Parameters is forced. A .hyd carries model inputs, not results, so there are no published flows to import at all.
• Any results file without ponds — routed or rational-only — → either basis is valid and the choice is yours. Basin Parameters lets HydraStorm re-time the flows along the pipe network you actually drew; Peak Flows keeps HydraLink's numbers verbatim.

Which one your project wants

On the Basin Parameters basis a structure's Q is re-derived from the accumulated ΣCA at that structure's system Tc — the longest travel time reaching it. Where two basins with different Tc meet, the shorter basin's area gets priced at the longer basin's (lower) intensity, so the combined Q is less than the sum of the two basins' published peaks. That is the rational method behaving correctly: two peaks that arrive at different times do not add.

On the Peak Flows basis nothing is re-priced. Each basin's published peak enters at its matched structure and the peaks simply add downstream, so every structure's Q is still the number on the HydraLink drainage-area map. That sum is the conservative envelope of the re-timed result — it is never smaller. Both accountings are in common use; pick the one your reviewer expects, and be aware that switching bases changes computed flows throughout the network.

A rational-only export (one published by HydraLink's Civil 3D palette, or any file marked as carrying no routing) supports both bases. What it lacks is routing, not flows: it publishes a peak per basin either way. A structure fed by something the drawing models as a pond or culvert therefore receives that element's inflow on either basis, un-attenuated — HydraStorm flags this on the file and on the affected rows. Solve and re-export in HydraLink when you need attenuated numbers.

On the Basin Parameters basis, any peak flow that an earlier import (or an earlier Peak Flows Only design) left on a structure is excluded from the calculation and named in a warning. See What Enters the Rational Accumulation.

When the model starts or stops attenuating

A pond and the rational accumulation cannot coexist: storage attenuates flow, and ΣCA does not. If a re-published .hyd or .hlresults now routes flow through a pond that this network continues below — a reachable pond, in a project running on Basin Parameters — HydraStorm does more than warn: it refuses to calculate at all until the basis changes. A pond the storm drain merely discharges into at its outfall, with nothing modelled downstream of it, is not reachable and does not trip this.

• A reachable pond appears: HydraStorm names it and asks you to convert the link to Peak Flows. Declining leaves the project in a state HydraStorm will not compute — not just "unattenuated," but blocked — until you convert the basis here or switch the whole project to Peak Flows Only and enter the flows by hand. Revisit the Import Basis in Project Settings if you change your mind.
• The last reachable pond disappears from a project running on Peak Flows: HydraStorm offers a return to Basin Parameters. Staying on Peak Flows is equally valid, so this one is only ever an offer.

Accepting either prompt converts the basis and recalculates immediately.

Routed pond outflows

On the Peak Flows basis, a structure matched to a HydraLink pond is treated as the pond's outlet: its routed outflow replaces the flow arriving from upstream instead of adding to it, because the routed outflow already accounts for everything draining into the pond. That replacement is per storm, and the credit is only ever taken with an outflow the file actually published for that return period. If HydraLink published a 100-year outflow but nothing for the 2-year storm, the 2-year run takes no attenuation credit: the structure accumulates like any other, its stored flow adding to the arriving flows instead of replacing them — a conservative sum, never a substituted release.

Whenever the credit is taken, HydraStorm reports it as an Info message on that structure, for example:

Read that message as a prompt to check the two models agree: if a lateral exists in the drawing but not in the HydraLink model, its flow disappears below the pond and nothing else would tell you.

A pond is two structures

A pond breaks the network. The storm drain discharging into it ends at a headwall or outfall structure at the pond; the outfall pipe below it starts at the outlet control structure. Those are two structures and two sub-networks, and HydraStorm calculates disconnected sub-networks independently — so 50 cfs arriving and 30 cfs leaving never accumulate across the storage, which is right, because they are not the same water event. Draw it that way and there is nothing else to configure.

Drawing the pond as a single pass-through structure connects two systems that are not connected, and three things go wrong at once:

• the arriving flow is summed with the routed outflow, double-counting the whole basin above the pond — unless the link is on the Peak Flows basis, where the routed outflow replaces it;
• the HGL propagates straight through: the outfall pipe's backwater climbs into the incoming trunk instead of that trunk ending at the pond's water surface. This one is wrong even when the flows come out right, which is why it is reported in every hydrology mode;
• in a rational mode the upstream ΣCA passes through un-attenuated, so every structure below the pond is priced on the full upstream drainage area.

HydraStorm reports this as a Network Issues row the moment the network is read, not just as a calculation warning — it is a drafting fault, and the fix is the drawing rather than a setting. The calculation adds the numbers behind the double count so you can see which part of the total is counted twice.

Ponds in a .hyd link

A .hyd carries inputs, not results, so nothing in it is routed and the only basis it can drive is Basin Parameters — there is no Peak Flows basis to fall back to on this channel. If the linked plan contains a pond this network continues below (the same reachability test as above), HydraStorm refuses to calculate rather than pricing every structure below it on the full, un-attenuated upstream drainage area. A pond the drawing only discharges into at its outfall, with nothing modelled downstream of it, is not reachable and is not refused.

The remedy is never to delete the pond — the storage is real, and hiding it from HydraStorm would just move the error into the design instead of the software. That pond's routed outflow is not missing: it is already sitting in the solved .hlresults the same HydraLink project exported, found by filename convention (<project>_<plan>.hlresults, next to the .hyd). When HydraStorm finds that file, Project Settings offers a one-click swap that re-points the link, loads it, imports the flows, and re-checks the configuration. When no companion file is found, solve and export the plan from HydraLink, or switch the project to Peak Flows Only and enter the flows by hand.

Culverts are not treated this way. A culvert is steady conveyance with no storage, so it earns no replacement credit: its routed flow is imported as an ordinary local inflow and accumulates with whatever arrives in pipes. That is only correct when the culvert's tributary system is not also drawn in the HydraStorm network — a mid-network structure matched to a HydraLink culvert would carry both the culvert's routed flow and the same water arriving through the upstream pipes, counting it twice. Match culverts where they bring outside flow into the system, not where they sit inline on pipes you are designing.

What an import may overwrite — and what it may not

An import lands flows for every storm the linked file publishes, not just the design and check pair. A storm that drives a published number — the storm drain design or check storm, a culvert or inlet module storm, or any analysis storm in a storm-first project — always goes through the same per-structure review dialog, and so does any storm whose slot already holds a different value, whether or not anything computes it yet. A number somebody typed is never overwritten without being shown first. What is left is genuinely inert: it lands quietly and the status line names the storms (“also stored 10-yr, 50-yr for later use”).

Unchecking a row in that dialog keeps the structure's current flow and its current pond designation. Declining an update and then having the structure re-labelled as a routed pond outlet would change how the flow you kept accumulates, which is not what declining means.

A re-import also reports what it lost. An element that has disappeared from the linked file, or that is still in the file but no longer matches a structure, is listed by name — its structure keeps the flow from the last import, and without the notice nothing would ever say why it stopped updating.

The same goes for a storm the file stops publishing. HydraStorm records which return periods each element published when you imported it, so if HydraLink later drops the 25-year event the review shows a row reading “25-yr — no longer published” on every structure still carrying a 25-year flow, and offers to clear it. That row is the one row in the dialog that arrives unchecked: keeping a number is the safe direction, and the point is to tell you the flow has stopped being refreshed, not to delete it for you. This matters most when a culvert or inlet module runs that return period — it would go on computing with the stale value with nothing able to say so.

Projects saved before this was recorded, and .hyd links (which compute one storm at a time), carry no such record. HydraStorm reads that as unknown rather than as “published nothing”, so no removals are proposed until a results import has established the baseline.

How Flows Are Matched

HydraStorm matches HydraLink elements (basins, junctions, ponds) to Civil 3D pipe network structures by trying each of the following in order, stopping at the first success:

1. Exact name match — the HydraLink element name matches the structure name exactly.
2. Name match ignoring prefixes — common prefixes such as "Basin-" or "Jct-" are stripped from both names before comparing.
3. Partial name match — one name is contained within the other.
4. Close name match — near-misses and typos are matched when the names are at least 60% similar.
5. Location match — matched by coordinates within a search radius you set in Project Settings (default 5 ft).
6. Manual assignment — anything still unmatched can be assigned by hand in the Hydrology Table.

Newer HydraLink exports tag each basin, junction, pond, and culvert with a permanent identifier: either the Civil 3D structure handle or an ID HydraLink assigned when the element was created. When that tag is present, HydraStorm goes straight to the right node on every later import or live sync, and none of the name or location steps above are needed. Those steps remain the fallback for older elements without a tag, most often the first time you import a given HydraLink project.

Shared Inlets — Several Basins, One Structure

Two or three drainage areas often discharge to the same curb inlet. You can model that in HydraLink's Civil 3D palette by marking each of those basins at that one inlet, instead of adding a junction whose only job is to say they meet there. HydraStorm lands in the same place either way: the basins accumulate at that structure exactly as a junction would — areas sum, C is area-weighted, and the longest Tc governs — and their published peaks add.

The distinction that makes this work is between a point you picked and a point HydraLink computed. A marked discharge point is an instruction, so HydraStorm matches it to the structure you put it on and does not pass it over for a nearby inlet, and a second basin marked at the same point joins that structure rather than being pushed to its next-nearest one. A basin with no marker carries its computed centroid, which is a guess: two centroids landing near one structure are a coincidence, so the first claims it and the second is matched elsewhere with a note saying so. Either way the review grid tells you what happened before anything is applied — a shared inlet reads "Shares 'CI-1' with 'A', 'B'".

Two limits worth knowing. A basin never joins a structure already matched to a junction or pond, because that element's accumulated or routed flow already accounts for the same water. And in Rational (Basin Parameters) mode the structure is re-priced from the combined area, weighted C, and Tc at the system's time of concentration rather than adding the published peaks — the same difference you already get at a junction, and generally the smaller number.

Marking basins requires a HydraLink version that writes the tag. Files exported before it, or basins whose position has been moved since export, simply behave as they always have.

Basin vs Junction Intelligence

HydraLink models often include both basins (drainage areas) and junctions (confluence points that accumulate basin flows). HydraStorm does not store the junction as its own record: when a junction is matched to a structure, each of its member basins is expanded into a suggestion at that structure instead, labelled via the junction, and you accept them the same way you accept any other suggested basin (see HydraLink Junction Intelligence). A junction is either fully on one structure or it is not — there is no partial state, so double-counting the same watershed once through the junction and once through a member basin cannot happen. The result at the structure is identical to assigning the basins one at a time: summed area, area-weighted C, and the largest Tc.

Flow Sources

Different HydraLink element types provide flow data from different result fields:

Element Type	Flow Field	Description
Basin	peak_flow_cfs	Peak runoff from the drainage area
Pond	peak_outflow_cfs	Routed outflow after detention
Culvert	peak_outflow_cfs	Outflow from the culvert analysis

Live Sync & Flow Review

Once a linked .hlresults file has been imported at least once, HydraStorm keeps watching it on disk. When you recalculate in HydraLink and it re-publishes the file, HydraStorm reads the update automatically and works out what changed at each matched structure before touching any node.

Reviewing the update

If flows changed, HydraStorm opens the HydraLink Flow Update dialog listing every affected node/storm combination: the node name, the HydraLink element(s) feeding it, the storm (return period, with "(check)" for the check storm), the current flow, and the new flow. Each row has an Apply checkbox, checked by default.

• Click Apply Selected to accept the checked rows. HydraStorm updates the design and/or check flow on those nodes and recalculates.
• Click Skip All (or close the dialog) to leave every node flow exactly as it was. You can still reload manually from Project Settings later.

Flows that didn't change are never listed, so on a large project you only review real deltas. If a previously matched HydraLink element is missing from the new file (renamed, deleted, or dropped from the plan), it's called out below the table: the node it was feeding keeps its last-applied flow until you resolve it.

What triggers it

Live sync applies to a linked .hlresults results export once you've matched at least one flow from it. A linked .hyd project file is watched too: HydraLink computes basin and junction hydrology locally from that file rather than exporting pre-computed flows, but a change on disk opens the same review dialog described above, seeded from whichever channels the project has actually imported before — matched flows (once a results import has established them), matched basin area/C/Tc, or both — plus the pond census the reachability rule needs (see Import Basis).

If HydraLink marks the results file as out of date (inputs changed since the flows were last computed), or none of the storms in the file match your project's design return period, HydraStorm shows a status bar message describing the issue instead of opening the review dialog. The check is against the design period only, even when a check storm is configured. Recalculate and re-export in HydraLink to clear it.

Provisional flows from the Civil 3D palette

HydraLink's Civil 3D palette can publish flows when you save a .hyd, so you can reach HydraStorm without waiting for a desktop solve. Those flows are provisional: they are Rational peaks with no routing anywhere. A node the drawing marks as a pond or culvert arrives as an ordinary junction carrying its inflow, not the attenuated outflow a routed solve would produce, so any inlet fed by one is overstated by exactly the attenuation the pond exists to provide.

HydraStorm labels these files wherever they appear. Project Settings shows the source alongside the plan and solve time, and the flow update dialog carries a banner above the grid:

The flows are still usable, and applying them is a normal thing to do while a design is taking shape. Treat any pond or culvert node as an upper bound until HydraLink solves.

Both the palette and the desktop publish to the same file, so this is one channel whose source changes rather than two competing files. When a full routed solve later lands there, HydraStorm applies it and says so, since that is an upgrade, not a conflict. A palette save landing on top of a routed solve is reported the other way, as routed pond and culvert outflows going away until HydraLink solves again.

Where HydraLink could not compute a node for a given storm, it publishes nothing for that storm rather than a low number. HydraStorm leaves that node's flow alone instead of writing a zero, so a missing result never quietly dries out a run.

Basins That Reach No Structure

A linked HydraLink model can carry a basin that ends up feeding nothing in the drawing. It is an easy mistake to miss, because a basin like that simply contributes no flow anywhere — there is no obviously wrong number to notice, only a downstream flow that is quietly short. HydraStorm counts these basins on every calculation and names each one and why:

• On the Basin Parameters basis: a basin the import never matched to a structure, plus any SCS or other non-rational basin in the linked model at all. This basis only ever carries C·A·Tc, so a basin whose only published number is a peak flow has nowhere to go here no matter what you do in the Basin Assignment dialog — its remedy is linking the solved .hlresults on the Fixed Flows basis instead.
• On the Fixed Flows (Peak Flows) basis: a basin whose own flow mapping was never accepted onto a structure, and that has nothing accepted downstream of it either — a basin draining to a mapped junction or pond is already accounted there, so only a basin whose whole discharge chain misses the drawing is flagged. Its remedy is the flow assignment grid in Project Settings → Hydrology.

A small count badges the Tables button (Basin Parameters) or the Settings button (Fixed Flows) — whichever dialog is the remedy; on the Basin Parameters basis the Basin Assignment menu item itself also turns amber with an inline count. The calculation warning names every unfed basin along with its reason, for example:

A basin added in HydraLink after you have already imported reaches this the same way a changed flow does: re-saving the linked file opens the review dialog naming the new basin, and accepting brings it into the Basin Assignment pool (or the flow grid) where the count above can see it. It never arrives silently counted as fed.

Rational Method from HydraLink

On the Basin Parameters basis, HydraLink provides basin parameters (drainage area, runoff coefficient C, and time of concentration Tc) rather than peak flows. This allows HydraStorm to perform its own Tc accumulation through the pipe network and interpolate rainfall intensity from the IDF data that came across with the link.

This is particularly useful when the pipe network layout differs from the HydraLink junction network, since HydraStorm will recompute travel times based on actual pipe lengths and velocities.

Because the accumulation is pure ΣCA, peak flows that came across on an earlier import are not added to it. If you need HydraLink's solved numbers to govern, switch the link to the Peak Flows basis.