2D or Not 2D: Next-Generation Autodesk Flood Modeling Workflows

MATT ANDERSON: Welcome to AU 2023. A little bit of a Shakespearean title-- 2D or Not 2D-- Next-Generation OF Autodesk's Flood Modeling Workflows. My name is Matt Anderson. I'm the Hydrology and Hydraulics Modeling Lead at Gage Engineering in Houston.

Little safe harbor. When I wrote this, I was an Autodesk employee, so there may be some things that I may say. Obviously, follow the guidance. We'll have some future-looking things and future-looking comments in here. Take that into mind if you're making investment or purchasing decisions.

So under the course description, there's a lot of words. But pretty much, where are we today, right? Public domain software, like HEC-RAS, has made 2D hydraulic calculations accessible. Sometimes the simplicity could be debatable, but hydraulic modeling and hydraulic calculations could be a foundation for a way forward.

In this class, we're going to look at 2D hydrology and hydraulics, using Autodesk tools, such as Civil 3D or Infoworks ICM. So let's learn how to improve your hydraulic skills, and discuss the fundamentals of 2D integrated catchment. We'll go through the data workflow. We'll apply some basic 2D rain-on-grid hydrologic modeling methods-- actually, maybe, I think that should be hydraulic modeling methods-- implement some basic 2D hydraulic tools for existing and proposed conditions, and discover some of the unique challenges we have over some legacy workflows.

A lot of words. Let's go with the simpler version. We're going to review some of the challenges to physical simulations of existing proposed conditions. We're going to learn some of the basics of 2D rain-on-grid hydraulic modeling. And we're going to overcome some of the unique challenges that a 2D hydraulic solution offers over legacy workflows. Caution-- water on road during rain.

So a little bit about me. Who am I? Husband of one, father of five. In the gloom of the early morning, I'm known as CAD at F3. There's a photo of my family.

I'm a professional engineer, a hydrology and hydraulics nerd. As I said earlier, I am the modeling lead at Gage Engineering I'm a former Innovyze Product Manager, working on the Storm, Sewer and Flood products-- Infoworks ICM, XPSWMM, XPStorm, InfoSwim, InfoSewer. And I'm also a former Autodesk Product Manager, on the Civil Infrastructure team.

As the modeling lead, I'm a wearer of many hats. As a modeler-- I don't know, I think we're at the top of the food chain. We consume everything, all the other disciplines. Hey, I don't know. It could be the top of the food chain, could be the bottom, right?

Our challenge-- identify where and how much water runs off of a site or a city. If we build every square foot, as many of our clients would like us to do, what do we do with this extra water? We deal with regulations for multiple jurisdictions, whether it's the Flood Control District, local municipalities, FEMA, state.

We deal with rainfall. What rainfall? Which rainfall? What? How deep? How urgent? How fast? And then we worry about the uncertainties associated with plausible designs.

As an engineer, we have tools. We have tools in our toolbox. I don't exactly have a rustic toolbox like this in my garage, but I want to use this image of a toolbox-- an older toolbox-- to foster and reinforce a prime message about our way forward.

These old tools still work. They allow us to tighten the nut that holds our children's bike tires, or keep the doorknob on, or allow us to assemble the IKEA bookshelf. Well, I don't see an Allen wrench in there. Or maybe keep the kitchen sink from spraying the buffet that's been aligned so nicely on the kitchen counter.

They help us keep that immediate elements tight, working correctly. In the end, these tools continue to hold value and usefulness today, regardless of how old this those tools are. Our tools tend to evolve. But in many cases, our tools tend to have a single purpose. And much of that purpose is built into the rules and regulations that surround our industry, especially around hydraulics.

After helping my parents pack a residence that's been in the family for three generations, I'm amazed at some of the gadgets, and gizmos, and tools that have faded away, primarily for some newer tools. I take this into to effect as I lead the many EITs that I work with, teaching them basics-- the foundation, the root-- using tools like HY8 or Microsoft Excel, to compute inlets.

Our modern toolbox is not too similar than these modern digital tools that are shown here, right? While technology has been applied to many of those rustic tools in functions from the slide prior, these tech-assisted tools assist that toolbearer-- me, maybe you-- to do more, potentially, with some technology.

What once was a Phillips or a flathead, maybe a hand-cranked drill, now helps me create holes in my wall so I can hang curtains. This one cordless electric drill now helps me loosen or tighten the star screw, while replacing the broken bits on the family van, or drill holes, attach curtain rods-- depending on the whim and decorating that my family would like to have done. Or honestly, disassemble or assemble various elements, as we move from one location to the other.

This toolbox just has an interesting platform play-- the battery. All of these RYOBI tools come with a battery that's interchangeable. Thank you, Henry Ford. The battery pack for my drill works with the fan, which is wonderful for those hot, humid days at the ball field, here in Florida, or in the worklight, which allows my fellow F3 workout partners to see the workout of the day on the whiteboard, in the early gloom of the morning.

Now, our tools have a nice history. We've gone from observing behavior, like Emil Kuichling in the city of New York, understanding how the rational method works, or how the Army Corps of Engineers began to develop act two to using cards-- the old cards. Where are we today? Peak flow, rational equation to size inlets and pipes, time varying runoff to deal with the volume of runoff, tools for watersheds, tools for rivers, tools for pipe systems or sewers.

Today, much of our tools and our workflows helps us determine what our risk is, either to our shoes or to the infrastructure-- either the existing or the proposed. So let's take a look at where we're going. Let's start by discussing urban flooding.

Two reasons-- much of that urban flooding can be comprised by general trends. So let's just very quickly review some terms. Fluvial flooding-- of or found of a river. Typically, when we discuss drainage or flooding, typically everyone thinks HEC-RAS, right? That's fluvial. Heck-- Hydraulic Engineering Corps River Analysis System, right? River, right? So the rivers flood. Obviously, in this case, this is a nice, meandering stream between two mountains in a valley. That's HEC-RAS.

What I want to talk about in this presentation is pluvial flooding-- relating to or characterized by rainfall. I live in Florida. It's going to rain shortly and hopefully-- and I'm pretty sure it will, knock on wood-- I'm not going to get wet, because I'm going to stay indoors. But rainfall, depending on when and how much rain we get, impacts our built infrastructure. It's not addressed, always, by FEMA flood maps.

So the City Resilience Program and the World Bank published a 177-page publication, about a month ago, that helps us illustrate some of the challenges we have for urban flooding-- the pluvial kind. I'm going to reference a number of their figures, and facts, and tables that illustrate this very well. Much easier to borrow than to create, in most cases.

Especially for urban flooding, we have these five steps. Understand, right? We take the setting, we take the challenge. Houston-- Hurricane Harvey. Australia-- the devastating storms. Both of those are pushing the discussion on to that next level. We're beginning to understand how everything works together. We

Can identify. We have the results. Who submitted claims? For example, in the city of Houston, we know where those flooded structures are that submitted claims. We're modeling the city, to identify and study the streams, the storm sewers, the ditches, the terrain, to understand how all of it behaves.

We're evaluating options. If your house flooded, can we help that? There's a benefit. We're doing as much as we can with infrastructure dollars that we have, to evaluate options.

We're finding those designs, on the implementation side, that will have the greatest benefit to alleviate that cost. And hopefully, if we do it right, we'll keep tabs on it all, and how the city changes and evolves over time.

So to understand the impact of that urban flood risk, or that pluvial flooding, we need some data. We need data around the terrain. This is the data we get from the amazing technology, like LiDAR, which ReCap, fills fits very well. We, in many cases, get this via GIS, whether it's QGIS or Esri ArcGIS Pro, and other terrain surface applications that create a raster image of the ground around us today.

Our design packages, such as AutoCAD Civil 3D or Infraworks does an amazing job of converting points, alignments, roads, profiles, feature lines, and corridors into, ultimately, a proposed ground surface for the projects that we are designing. I've seen amazing growth over the past decade, and I expect to see more model-based deliverables.

We see that currently in Texas, with their recent drive towards a digital deliverable for [INAUDIBLE] projects. No longer will a 50-foot section that matches existing ground be good enough, if Station 1033 misses the tie-in at the right of way. The model will rule.

Our conveyance networks are underground, or potentially even are surface channels. In many cases, these are owned by someone. They're assets-- assets for the city, the municipality. Occasionally, we will send out surveyors to measure it, locate it. Or if we have a well-to-do city, we have this data in some asset registry-- in GIS or some repository.

We may have to clean up a lot to make this simulation-ready. I don't remember-- or I do remember, many years ago, AutoCAD DWG drawings of pipe networks with text. Not a lot of data. We know where, we know what size, but we need to get that simulation-ready. In the design world, right now, these are our pipe networks.

In Civil 3D, we have a lot of data. I don't envy my former colleagues as they try to determine that pipe network in Forma moving forward. What's necessary, what's relevant? The pipe network in Civil 3D is a bit old. And having been part of the various efforts from my time at Autodesk, from QA to beta testing to QA, during my time in the business consulting or as a product manager with Caltrans, and the infrastructure part modeler, Civil 3D pipe network still has flaws.

But this amalgamation of the physical and ultimately the engineering is going to come down from where Civil 3D, InfoDrainage, InfoWorks ICM, potentially HEC-RAS for the bridges, Inventor for their pumps, or potentially what the competition is doing.

Remember the little old lady from the Wendy's commercials? Right? I'll do my best. Where's the culvert? The other part is land use. It defines our roughness. It defines our infiltration, right? A little tongue in cheek. This information meticulously maintained by our cities and the county GIS departments, potentially from remote sensing. [CHUCKLES] They might have it.

For design projects, we use lines, polylines, hatches to represent this potential new improvement. At some point, to get this into InfoWorks ICM, we need a polygon that represents what that coverage is, and does, and how it behaves. Individually, a rough disk polygon and an infiltration polygon are two separate lines that could represent the same element.

With recent developments for buildings, which represent a building's roughness, its infiltration, its elevation, its mesh all in one object, I think we see a general trend. Many years ago, InfoWorks did this with design roadways for inlet analysis or, originally, the Project Boulder partnership that we worked on with Hydronia that converted color in InfoWorks to a roughness.

That was almost eight years ago. But these are the basic building blocks of the hydraulic model at a very high level. As we move on into this next generation, we need to move away from spreadsheets and nomographs. We need to begin to divorce ourselves of some of the constraints we found comfort in as we get into that process towards change.

We need to expand simplified methods and move towards things like Saint-Venant equations, the conservation of mass and momentum, more physical-based engineering, less voodoo hydrology or hydraulics. I don't want to spend a lot of time talking about these equations. I spent too much time talking about those with some SSA classes back almost 10 years ago. Wow.

As a quick aside, I troubled myself with the title of this presentation, "2D or Not 2D." Right? 2D kind of thinks flat lines, right? You know 1D, right? Hydraulically, it's a vector. Right? It's a line, right? We deal with a 1D model of velocity in a single direction, right? Down a pipe, down a channel.

And much of what we hear throughout AU 2023 primarily is about 3D, right? So 2D or not 2D kind of-- anyway. My concerns. You're here for the right reasons, hydraulic modeling, 2D. The 2D calculation allows that vector to potentially go in two directions, right? It frees us from that single direction down that channel or pipe.

In this case, we have a spatial component to it. Right? Once we get outside of just the single vector, we have the terrain, which then can be schematized into a number of methods used to calculate depth or elevation together with the direction of flow across the terrain.

Now, the old way to model pluvial is to lump everything into a catchment. Right? Water down to a point. While this is still valid today, that data is only good to that point. Right? If you need to know how deep the water is somewhere within that catchment, we have to interpolate.

I think the next generation, we need a better answer than just single interpolations. The next generation of flood modeling is here and has been around for some time. And we need to get beyond a simple understanding of what just leaves the catchment. That's really 2D modeling.

So figure 2.6 in the Urban Flood Handbook illustrates this pretty well. Right? We have our DTM. We have our vegetation and other structures. The quality of that terrain is key. Well, this image doesn't show InfoWorks ICM. It simply illustrates primarily the two different modeling methods.

A fixed grid, right? A series of squares or a flexible mesh. That fixed grid primarily found in XPSWMM, and TUFLOW, even things like FLO-2D. Right? XPSWMM and TUFLOW have what's called quadtree, where we take that square, cut it up into four squares, and go on and on. Right?

ICM and HEC-RAS is kind of a flexible mesh. A bit different, right? Whereas it's got a variable grid, variable mesh associated with it. Polygons can be rectangular. ICM is built on triangles, right? They're different, and they use that flexible mesh algorithm in ground surface and roughness, in infiltration spatially. Right?

We see that the velocity can go in at least those two directions, right? In all cases, we have a 360 degree from that center of cell or center of mesh element in any direction. Right? The 2D model is a distributed model. We don't lump. We don't average. It's the key benefit of the 2D model.

Rainfall-- well, this hasn't changed much over time. Right? It's a depth over time or an intensity. Well, I guess you could say it does change over time. But that's just the nature of the beast. One way or the other, we need rain. By definition, pluvial is rain. A purist might haggle with me. It's really precipitation.

Well, ICM deals with intensities. It can either be a design rainfall or actually measured event rainfall. And there are a number of ways of getting it in there. For this, we're going to use the Atlas 14 rainfall in the NOAA design generator.

It's going to reach out to Atlas 14, pull in our depths, and then will allow us to leverage some of the stationary or non-stationary elements for our rainfall distributions, whether they're Huff or the the sort of conservations of NRCS rainfall distributions for Atlas 14, or Bulletin 75, which kind of superseded the Huff.

In many cases, HMS has what's called alternating block, where we take the varying intensities in from Atlas 14 and position those on either side of a centroid. Right? I probably should spend more time talking about this. But I'll leave that to potentially blog and in the future.

Key element. Subtracting losses from rainfall hyetographs avoids applying spatially-distributed infiltration. Let that sink in for a second. Subtracting losses from rainfall hyetographs avoids applying spatially-distributed infiltration. In essence, when we take some of the rainfall away from that hyetograph, we're lumping. We're averaging the losses on the watershed, right? It comes into play.

I'd advise you not to do it. Reconsider that. There are easier ways to get that to happen. So when we look at land use and infiltration, this is that spatial element. Right? We get this from our either digitized or remote sensing, maybe our GIS repository. Right?

This is the hydraulic element of our hydrology, right? Where is infiltration happening? Right? I'm just going to look at the InfoWorks network. The SWMM network has some of these as well. But green app, constant and fixed infiltration, Horton infiltration, deficit and constant loss, or, as I'm used to calling it, initial and continuing loss, which showed up in 2024. Right?

I will say as we get into our Houston models, we're finding that during our calibration with three of our large storm events, Tax, and Memorial, and Harvey, the application of average infiltration loss was taken out of the rainfall. Right?

Well, we've now lumped that rainfall, that infiltration, if you will, so that the only place where that runoff volume is valid is at the outfall of our structures. We've lost that runoff probably where it hurt the most. Those neighborhoods probably at the upper reaches of these watersheds, where insufficient pipe capacity and high imperviousness was unable to escape and flooded those structures.

Now, I think we have a pretty good model fit. But from the background, I think pulling losses off the rainfall was probably not the smartest thing to do. For Houston, we're getting into the Q/C quality control side of things. We're beginning to look at how we've defined the 2D mesh to avoid elements such as this upper corner with the one.

It's a broken channel flow. This is about a 10-foot-wide flat bottom. But you can see in looking at that aggregated 2D mesh we have a couple of very disjointed almost 5-foot differences in the bottom of channel. Right? Ultimately, we've identified here that many of our break lines are in misalignment when we've applied those to the engineering model.

In the lower left, we're looking at the match between two sections of model, where we ultimately have a jump during the validation of one of the models. This, again, was fixed by looking at the break line placement, turning ICM's contour lines on, and reviewing where the break lines fall on the mesh and the terrain so that we can avoid a flip in the bidirectional channel flow that caused a number of sudden reversal of flow as we looked at each element down there.

These arrows helped us identify what was going on and why we had, in essence, a 6-foot jump in the hydraulic grade line. In the end, we run these models to understand where it floods today so we can propose improvements and can document the benefit of those improvements.

Can we drain these areas with deeper improvements, more storm sewer, larger storm sewer? Linking that analysis of 2D to the design process is where I think we'll be headed in this next-generation flood modeling workflow, especially with design. Let's look at that workflow.

Today, the Autodesk workflow is primarily in three buckets. Our source data, this is our AutoCAD Civil 3D, our Esri ArcMap, QGIS, InfoWorks ReCap, the data collection, if you will, whether it's taking existing conditions or designing new conditions. That's where we have sources. We're doing our plan production there.

We're pulling it together. We're adding some engineering data, some engineering properties, the infiltration. Right? What does a polygon of asphalt look like in a corridor model? Right? It's a polygon and potentially can be extracted as a solid.

Doesn't tell us how rough it is, whether it's pervious or impervious. Right? We do that today in InfoWorks ICM. We add that engineering data, that hydraulic engineering data, to that ICM model. And occasionally, we'll be going back and forth. The storage and compute side, where do we store all of this engineering data. Right?

So prior to Autodesk's purchase of Innovyze, we had the workgroup data server. You still have that today, but that's local. Right? We're sharing data across a number of engineers on premise, right? We have hardware. We have IT-associated costs associated with NVIDIA video cards and large volumes of file servers and storage. Right?

Well, now with 2024, we have the Info360 tenant, the workgroup now in the cloud. AutoCAD or InfoWorks ICM 2024 has the ability to store that data in the cloud. And we also have the ability to do those compute in the cloud as well.

Now, I think this changes the game. Right? That unlimited compute capacity enables us to do things which we were limited to before on premise. So let's look at this workflow.

This little animation, it's our shaker surface. Right? From the pipe network tutorial, right? We're going to export this surface. We're going to make sure we're going to send out those points and lines out to LandXML. It's a simple workflow, right?

We're going to export that. We can occasionally do that because I think the Civil 3D surface engine is extremely beneficial when we merge surfaces. Right? And we'll see that when we get into the proposed design, right? This workflow, it's pretty simple. It's pretty easy to do.

Today, obviously, a much larger element. This is the TIN surface, right? So we'll skip this, right? It's great for design. It's going to bite us ultimately on some of the round trip back and forth because ICM doesn't export those results via LandXML or via a TIN-type surface. It's a lot of GIS work.

InfoWorks ICM, pretty simple. Import InfoWorks, ground model TIN, LandXML. We did quite a bit of this last year in my AU class. And we got more of it here today. I don't want to get into the details of that. But we can begin to look at those TIN surfaces.

I think I've got existing final ground with the building pad, final ground, and I've got a pond in there. Right? So I have a number of TIN design surfaces there. Right? We can do some simple subtraction and addition here in ICM, but there are some limitations there.

But ultimately everything is associated with a theme. Now, I'm not a huge fan of the HEC-RAS terrain color theme. It's pretty jarring, but it's great for visuals like this. Right? I've got my blog there. Talks a little bit about the themes because ultimately I can never remember what those color numbers are between HEC-RAS, and QGIS, Civil 3D, and InfoWorks. So I just write it down there.

ICM does in the key show you really what those ranges are. Get used to that. It's a nice way to look, and help edit, and work there. It's pretty nice. For rainfall, we're going to look at the NOAA Atlas generator. Right? In this case, this came from XP and expanded upon in ICM, where go out to the web, pull the Atlas 14 rainfall depths, and either apply a temporal distribution, something like alternating block, which is used in the Houston area in HEC-HMS.

I'm going to just go ahead and grab the 24-hour, 100-year storm. And I'll use this for my simulations. This is nice because it has that flexibility if you want to change where it peaks from the 50. You can go there, or you can leverage ultimately an ensemble, which I'm very used to, to do a critical storm analysis in places like Illinois, Minnesota, or Florida, where we look at varying peaks or varying rainfall durations with that Atlas 14 peaks.

Very helpful to understand the true impact of a rapid rainstorm because I can tell you, from living in Florida and living in Oregon, rain's very different. So we get that. In this case, this is alternating block. Right? Right at the 12-hour peak.

Then next, we need a mesh. In that mesh, we need a polygon. Right? It's called a 2D zone. In this case, I'm going to extract the boundary of that Civil 3D shaker surface, and kind of place it on the C TopoBoundary layer, and save that out to a block. Right?

In this case, import from AutoCAD allows me to select the layer. And any line or polygon on that layer, I can assign it the engineering property-- in this case, a 2D zone. That 2D zone has some engineering properties associated with it. Right? These aren't found in Civil 3D, not found in InfoWorks.

We're going to need to apply and work with the maximum triangle, the minimum element area, mesh generation type, boundary type, the terrain-sensitive flagging, and its maximum height variation, the rainfall profile, infiltration surface, and roughness. Right?

And we'll look at each of these a little bit more in detail in the coming slides. But that maximum triangle is the largest Shewchuk triangle over the surface. Shewchuk is just the algorithm, right? It's a little bit-- not a little bit-- it's different than the TIN process found in Civil 3D.

The minimum element area is the area in which ICM will aggregate any tiny triangles into a polygon mesh. Right? So ultimately, in this case, the maximum will roughly be 1,500 square feet. The minimum, just shy of 270 square feet.

These are key elements in defining, potentially even overdefining your 2D mesh. Lots of mesh elements means more calculation time. Right? We have mesh generation, classic mesh, a la classic Coke, and clip meshing, which is the next generation of that. It's newer. It's faster. Just use clip.

Terrain-sensitive meshing, I would turn it on. In this case, I took the screenshot before I turned it on. But it's going to take the average depth under that triangle to determine if it needs a smaller triangle. It's going to go with that maximum height variation-- in this case, 3.281 feet-- to determine whether or not that triangle is good enough. Right?

So if we have a 6-foot maximum height, we're going to take that triangle, and we're going to cut it in half. Right? And the Shewchuk algorithm handles that. I would use terrain-sensitive meshing and, depending on the level of your 2D analysis, tighten down that maximum height.

You can play with your minimum angle degree. And there's a good article on the Innovyze website that talks about changing that minimum angle. Right? Maybe taking it down to 15. And that just is the shape of the triangle, right? So if you have a lot of curves, we're going to continue to take that roughly equilateral triangle out.

That's going to create some pretty good size variation from large to small. But if you take that angle down to potentially 15, I think 12 is probably going to be your limit. But if you take that down to 15, we can get to those bigger triangles faster, saving you calculation time.

Do some sensitivity analysis there, right? Don't just take my word for it. Boundary type, right? This is our Christopher Columbus parameter. When we reach the end of the surface-- the end of the world, right? What happens? Right? In this case, our boundary type is a normal condition. Right?

It can be a wall. It can be a number of different variables. Normal, it's just going to fall off. Right? It's going to disappear. Each hydraulic engine all has different elements associated with it. Right? If we were to go back to the Project Boulder, we had to actually define where water entered and where water left along that boundary. Right?

Same kind of thing in this case. This is the entirety of that. Allows us to assume water is going to leave and fall off that boundary. Right? Rainfall profile is just a kind of a lookup between our rainfall and what our 2D object will be. It's just a lookup parameter, right?

And then our infiltration surface and our roughness all define what the default parameter is when we don't use any other polygons. Right? So you have an area, and we will hear shortly the shaker surface, and that pipe network three has a corridor in it. Right? So we're going to end up using the default values for roughness everywhere, except when we add that corridor surface in.

Now, I define soils in this model a little bit later. But we can apply that infiltration to any undrawn, if you will, areas. So next, we need to build that mesh. And if you come from Civil 3D or some of that, where the UI has been through some nice elements there, this command drives me nuts in ICM primarily because it fits a noun, verb, or object, then action workflow.

I don't know how many times I will pick the meshing algorithm, but I have forgotten to select my mesh in my 2D zone. Just a word of warning, right? So context-sensitive commands and verb-noun actions kind of drive you nuts a little bit. But that's my editorial rant, right?

So we're going to select our 2D zone. We're going to select the mesh parameters. We'll put our voids. We'll look at any break lines. In this case, with the straight LandXML, existing ground TIN, I don't have any break lines. So I should have marked break lines to none here, but I also don't have any walls.

So in doing that, the engine will then go and generate that mesh. Right? When that mesh is completed, we can take a look at that log. And then we can ultimately load that mesh when we're happy with that log. Right? That log is going to give us that description step by step.

In this case, it's a small surface. It's going to walk us through all of the interesting, fun things. It's going to talk to us about the minimum and maximum standard deviation of the triangles. It's going to do a lot of statistical stuff. Ultimately, get us to that existing ground mesh.

In this base scenario, it looks great. It's a nice set of even equilateral triangles. There's just about 3,000 vertices that created 5,760 triangles, which then gets aggregated down to 5,745 elements. In essence, we've created a couple and converted some triangles into a single element.

Again, this is different than a Civil 3D TIN triangle. The elements remain triangles, right? But the ground element, the elevation in which this ICM mesh element is, is a level playing field. Right? In this case, element 4,413, you'll see the coordinates, the x, the y, and the z associated with each of those corners of that mesh element.

Tells you the area of that element. Small elements means more total elements and therefore longer run times. Right? We need to always be careful based on the data that we apply to our model what our mesh needs to do. In this case, this mesh element, 582.4. Right? So we have varying heights associated with this.

But I kind of tease some of the engineers, the younger EITs. You got to think about this. This mesh element is kind of Minecraft. It's not cubic Minecraft. It's triangular Minecraft, but we have a bunch of steps. Right?

So we have assumed and smoothed, if you will, our surface into these elements. When we look at differences between the two sets of TINs, the Civil 3D TIN or the existing ground TIN, and our 2D mesh, you kind of can see as we zoom in here those blue dots are the points captured from that shaker surface. Right?

I used the kind of buggy surface export report to CSV from Civil 3D and imported those as points in ICM. Right? You kind of see in the yellow-- and I'll see if I can do this here. You can begin to see how that existing TIN triangles get folded in the underlying terrain and how ICM kind of glosses over that a little bit. Right?

Now, I want to draw a distinction here. There's no subgrid sampling, right? XPSWMM, TUFLOW, or HEC-RAS looks at each of these TIN triangles and defines either the edge and/or storage associated within each element. Right?

I think XPSWMM and TUFLOW have done an awesome job with subgrid sampling there. HEC-RAS kind of let it off a bit and looked at its process. But I think the edges associated with the TUFLOW engine, which is the engine underneath XPSWMM, kind of is the way to go.

Just know it's different. Once we have those elements, our rainfall and our mesh, we can begin to schedule a run. Right? All we need is a network, saved, committed. Right? If we have scenarios, those things validate it as well. Our rainfall event, in essence, we have the one storm, the NOAA rainfall.

And then we need to enter the duration-- in this case, 60 seconds. And we're going to run this for 32 hours. I'm not going to show you the full 32 hours because, obviously, leading into and leading out of that peak, well, is kind of dull, especially for such a small element. Right?

This allows us to run that simulation. And if you've got your Info360 tenant, this is going to push this up to the cloud and run that in the cloud. And those results will then be available for any of the members of your team within that tenant. It's pretty handy.

So when we want to visualize these results, we need to use themes. Right? There's a lot to these themes because there's a lot of data that is generated from an ICM simulation. Right? Some of these themes need a little bit of work and some manipulation to get to work really well.

Whether jumping between GIS, ICM, Civil 3D, lots of little bits and bobs where I wish this was over in the other application. I tend to do a lot of my review in QGIS, except when I need to begin to look at velocity vectors.

I can't seem to find an easy way to get the ICM output to show me the elevation or the depth of flooding-- excuse me-- in a triangle and also show me an arrow that is pointing in the direction of flow. I've got to use ICM to do all of that. Then again, haven't really tried that hard. Right?

You can save them. Save them to your network. You can save them to an IWS file for external sharing, right? To make this presentation, I had to play with a number of themes and tweak them to make these images visually compelling.

IWS is about the only way to share today. And this is something that I need here at Gage to standardize and share with my colleagues. And, actually, this is something that ICM needs to work on holistically across the platform. It'd be nice if they actually began to standardize across the Autodesk platform.

So when we look at these results-- and let me go ahead and just animate and talk through this. Right? We have that NOAA rainfall, right? Standard center-peaked storm, and I probably should have run shorter storms with more peaks in the earlier part.

But you can begin to see here as we step through the third and fourth hour, we are beginning to show flow aerials, where water is beginning to accumulate. The depth of flooding, the blue, is showing depths above a certain depth. Right?

So where do we see arrows but no blue triangle, we don't have sufficient depth at this moment in the simulation to call it flooded. Right? Maybe we're just getting the tips of our shoes wet. We don't need the yellow boots at this point.

Let's see if I can get this. As we get a little closer here, as we get into that 10th and 11th hour-- and let me see if I can kind of stop this as we get towards the 12th. Kind of begin to see that we now have a good channel, and we get up here. Oh, and I missed it.

So we have a pretty good definition of flow. We have this little snippet of storage here where the TIN is backed up. It kind of finally overflows and goes, right? At that peak 12 hour, I think we're at 12:05. Right? We've got arrows everywhere, but we don't have water greater than, I think, 4 inches on this surface.

So that's ultimately where we have the blue, right? But all the velocity arrows pretty much indicate to me that all of those areas are wet. So that's existing conditions, right? Pretty simple, right? A handful of elements and data that is needed, right?

From our proposed models, right? It's primarily our challenge is exchanging that data with our design applications. In this case, importing from AutoCAD, say, a polyline of that road shadow, soils, center line, flow line either as mesh-level zones or general lines to use as break lines, the corridor boundary to tighten up our mesh zone, and maybe our pipe network via the LandXML or, ultimately, through the tools that have come out recently for subscription customers that work with CSV exchange then go back and forth.

One way or the other, it's getting data out of our design application, applying those engineering properties to be able to run a simulation. Now, when we do that and we take all of those elements, changing that mesh 2D zone, adding the inlets and the engineering properties for the pipes, adding the culvert-- right? I think that's missing in the pipe network three tutorial, right?

I added all of that information into that Civil 3D model or actually into the ICM model. In this case, it almost doubles the number of vertices, which makes sense. Right? I cut in half the area for the maximum triangles as well as the minimum element area.

And you can kind of see the result here in our corridor zone, right? We've got tighter triangles in here. We have these general lines or the meshed zones aligned with our channel, or I should say roadside ditch. And we have elements that break along our flow line.

I kind of want to just drive this point home, right? As we zoom in here and I change the highlight here, those white lines are the elements, or I should say the white lines are the triangles. When you see white surrounded by black, the black is that element.

So it has aggregated that space in here into a single element. Right? It's looked at that. So all of this outside of the corridor on the existing ground is going to be one elevation in our flood model. Right? And we kind of see that in the mesh element plan.

We've got a lot of x and y values there, but it's all at that 666.3 feet. Again, drive that a little bit. There's a difference in how we look at surfaces and how we aggregate those triangles into the model. I think this animation shows a little bit faster.

And I just applied the same rainfall. I've applied the road surface as an impervious element. We have some pervious soil associated with that, right? You kind of saw it. It peaked and went away, right? So let me see if I can get back to that there.

So we have flow down that surface, kind of just as we expected. Right? But when we hit the road, we back up, and we ultimately flow over the road and on down. Right? Our flooding is a little bit different, primarily because the road is intercepting and shoveling water down.

So it's changed at the slightest element here to go. And let's see if I can get the video to stop right there. Back to that. So that LandXML, imported that. Again, engineering properties associated with the pipe network. I left all the pipes alone, as they are in the pipe network three drawing.

Pretty nice in that sense, right? But we gave them a continuous curb and gutter and then the sag inlet at the pivot there. Right? So all of this, very simple just to illustrate what's changed. Right? We can visually see water flowing over the road. Bad design, right?

I'll admit it. Bad design. I didn't want to mess with the design but threw the culvert in there just to make sure that we got some water across underneath that. But it's a tiny pipe, right? So we go through this, and we look at that. Right?

So we can very easily demonstrate that physical design from the existing through the proposed has an increase in flow of nearly-- and then ultimately at the edge of that downstream edge, we've got about a 6-inch rise at the edge. And all we've added is 1.3 acres or roughly 1.4 acres of imperviousness associated with that. Right?

It's about 6 CFS overall. The timing, yeah, imperceptible. It's primarily because of how badly we use the rainfall. Right? Would have much preferred showing you an ensemble design. But I didn't get into that at this point because wanted to keep this simple to illustrate the point. Right?

But that simple imperviousness associated with that, roughly double the number of mesh elements. Right? We can see that impact associated with that, right? When we look at that, it's tiny. Right? Impervious. There's no initial loss, no continuing loss associated with that. It's 100% runoff for that.

We've changed how that water begins to flow. The road has intercepted some of that. Some of it gets channeled. Some of it hits the pipes, right? We can see that in this plan and profile view in ICM, right? It's pretty tough to see, right?

It's a bad design, you know, but we have water over there. We have the sag associated with that. We can look at these elements, and we can look at those results. Right? We can look at the plan and profile. Yeah. Again, bad, really deep storm sewer design.

Not an advocate of the pipe network tutorial, but it helps understand what is going on. Right? And if you're not a visual person-- I am, right? We got numbers up the wazoo, right? For you to look at and review.

So taking that back to Civil 3D, right? We want to be able to take this back and export those results as flood contours. In this case, we get a 2D mesh. Right? We take the simulation. Take our final grid, right?