InfoWorks ICM and Civil 3D: A Flood Modeler’s Guide to Project Impacts

MATT ANDERSON: Welcome to Autodesk University 2022. Thanks for joining this technical demonstration. This is CE 50210 InfoWorks ICM and Civil 3D, A Flood Modelers Guide to Project Impacts. I'm Matt Anderson, a product manager for Innovyze, an Autodesk company. Prior to joining Innovyze, I was a product manager on the Civil Infrastructure team at Autodesk. So I've used Civil 3D in production and as a product manager, and done this in production for many FEMA map change studies.

Well, I'll show my age a little bit. I know what a punch card is, and I built models in similar formats. Times have changed. And times have changed considerably.

So as an Autodesk employee, I need to present you this safe harbor statement, so that you understand not to make any purchasing decisions based on what I might potentially slip up and say during this presentation. We may make forward-looking statements regarding planned or future development efforts, for existing or new products and services, regarding strategic priorities. These planned or future development efforts may change without notice. Purchasing investment decisions should not be based on or relied on, on these statements.

I'll point you to that second paragraph. If this presentation is viewed after the date that you watch this, these statements may no longer contain current or accurate information. And it's one of the things that as a product manager I'd love to make this video out of date pretty quickly, because we respond to your requests, and make your life a lot easier.

We're going to cover where we are today, kind of in our honeymoon phase between Innovyze and Autodesk. So as we continue, and my desire would be to hear from you as users attending this presentation, what those new needs are for how both of these products work together.

So the course content, this class should provide you a number of considerations as you work with Civil 3D and InfoWorks ICM. For some, InfoWorks might be brand new. For others, maybe it's Civil 3D. Well, maybe not. This is Autodesk University. I'm pretty sure most of the people attending this class are familiar with Civil 3D.

As an engineer, as a designer, as a modeler, we continue to understand how our projects impact the environment. As these projects develop, we continually stress local, potentially regional infrastructure. And we need to find new tools and new techniques to help us address those impacts. I think the news pretty much show us flooding events almost daily worldwide. Well, it rains.

So InfoWorks ICM is an enterprise collaboration tool that allows engineers or teams of engineers and modelers to evaluate a multitude of those rainfall events in the context of that entire environment. And Civil 3D allows us to document those potential flood damages across those wide ranges of scenarios.

So let's look at our objectives. So the data exchanged between Civil 3D and InfoWorks, we're going to dig deep into where we are today, give you a good understanding of those. We're going to look at scenarios. It's a bit of the optioneering of how as a flood modeler, how do we solve these problems.

How do we preserve that design data? So, we've done it as potentially a design in Civil 3D. We've sent it to InfoWorks ICM, done that analysis, determined our flood impacts. How do we document that? How do we return that to Civil 3D? How do we collaborate? As I said earlier, InfoWorks ICM is a tool, kind of an enterprise tool for a team of modelers. How do we collaborate together to build that model?

This isn't some tool that occasionally one person may use. Perfectly legitimate in that environment, but if you're a team of modelers, A, in New York City, you want a tool in which your team of 5 or 10 modelers can work together to build a watershed model to evaluate how that might impact your city, your county, or your area, potentially even how a single project may impact that entire watershed.

So communication, it's a key component really of both products. It's the process in which information really is exchanged. We take survey information, pass it off to the engineer. We take that information. We design plans. We potentially send those plans back to the surveyor to build it. We occasionally then take those plans and we have to get them approved at the city. And there potentially is quite a bit of red tape.

But we also then have to take those plans, or maybe that's just a simple not just a plan of engineering plans, but a plan that documents the risk to the community. We need to communicate that out to a whole host of potentially politicians, potentially just community members, contractors, or surveyors. There are a number of places in which data needs to be exchanged ultimately to understand either what to construct, what the risks are, and so on, and so forth. Project costs, all of that.

So let's go ahead and get started with the data and how AutoCAD Civil 3D can inform an InfoWorks ICM model, and go from there. So the data exchange, Civil 3D terrain surface I think is probably one of the key elements in these two use cases, the design and the modeling. So terrain surfaces and pipe networks, that's probably the top two primary use cases.

The other two on this list, lines/points/polylines we don't think of those as Civil 3D objects. They're just CAD entities at that point. But those can help inform a model or modeler in InfoWorks ICM. Rivers and sections, well, there isn't a river object in Civil 3D. But we can take the river and those elements that define a river, an alignment, section line groups, or sample line groups, and actually build a HEC-RAS model from those objects, and pull that in and take that and transfer that to InfoWorks ICM. Little roundabout way, but we'll go ahead and cover some of that.

So that outcome, that modeling, InfoWorks ICM, we'd have a lot of model input. We take ground models, so we can begin to see a little of the nomenclature shift surfaces in Civil 3D. We call them ground models in InfoWorks ICM. We've got the 1D pipe networks. We also have river networks in InfoWorks. Then we have 2D mesh models. All of those elements begin to help us represent that interaction of rain to physical infrastructure, whether it is man-made or natural.

And then ultimately, as we go through the process of converting rain to runoff, to potentially depths or hydraulic grades, we have model results. How do we take those model results and exchange that information? So let's go ahead and dig in.

Civil 3D, up first, we'll talk about that. We use it for that design and that documentation. So as I listed earlier, our Civil 3D surfaces, key element, we're going to ask ourselves a couple of questions on a project. One of the first questions to ask is what is that source of our surface information. Is this something we have asked a surveyor to collect? Is it a small project? Let's just say it's a new building in the floodplain downtown your City, USA. You're building something that might impact that floodplain.

So you've sent a surveyor to collect that information. That's a terrestrial survey. Maybe it is a large watershed study in the sense that you're grabbing, or collecting, or have collected, or you're using either GIS master data or LiDAR. Maybe it's a point cloud from ReCap that contains a large distance. That source of data helps us begin to understand and ask questions about what information to pass from Civil 3D to InfoWorks ICM.

As a project progresses, the scope of the surface change. Are we doing simply a planning study? Are we asking what happened, or how did this happen? In many cases, nuisance flooding might impact a city, and we've got some collection complaints. Maybe you're a city engineer, and you want to understand why yesterday's rain caused a bunch of people to flood.

You can use InfoWorks ICM to build a model to ask that question, and ultimately seek the answers of why that would happen. It's a planning study, right? It's potentially a single model, or a single surface.

If you are actually going to be, say, moving dirt, like we would when we do construction plans in Civil 3D, that's potentially multiple surfaces. And what do we want to do, and how do we want to convert that? I think I've let the PowerPoint slide deck leave a little hint there. Avoid the grid service. But let's deal with TIN surfaces.

So a TIN surface can import a DEM or a raster information in Civil 3D. So if you do have LiDAR or GIS data, that TIN surface can be imported into that or let me correct that. If you have regular raster type information that can be pasted into a TIN surface. A TIN is just a bunch of triangles, the grid surface, in essence. It maintains in triangles, and doesn't allow you to manipulate beyond that.

So we like the TIN surface primarily because it does give us the ability to export that to LandXML. So InfoWorks ICM can collect that and import that pretty easily. So back to our original questions there on the left. Terrestrial? Yeah, it's a TIN surface. We can export that. If we have single or multiple surfaces, depending on what we want to do, we potentially want to use the Civil 3D surface addition to collate our existing ground, pasting in our final ground, our final surface model. So we have one model to send to InfoWorks.

Now InfoWorks ICM can have a whole bunch of these TIN surfaces. And we can use those things accordingly. But we want that collection or that combination surface, that merged surface, if you will, as a TIN surface up to InfoWorks ICM via the LandXML format.

But potentially if you have LiDAR or GIS data, that information could ultimately, if you have that source, InfoWorks ICM can read that source as well. And then we just skip exporting that out of Civil 3D if you've already processed that.

Pipe networks, obviously an engineer, we deal with pipe networks quite a bit. Not everybody I know deals with existing pipe networks , like you see there on the left as a Civil 3D pipe network. I know a number of DOTs have begun to actually build existing pipe networks, primarily so that they can do projections and things like that for their construction plans when they say they widen the network, or widen the road.

But the question becomes is, are they flat CAD entities, right? Just lines with a label. Is it something that is simply digitized? Are they ultimately an asset inventory, potentially from GIS? Innovyze has another product called InfoAsset Manager, a similar tool in that fashion, where cities will build their asset inventory using InfoWorks. InfoAsset Manager collect that information and potentially store that in GIS. That information can be very easily collected.

So GIS files, potentially, if they are brought into Civil 3D, maybe they are just displayed as GIS elements. We don't really need to export that out. We can just simply use InfoWorks and connect to those data. But if you did build a Civil 3D pipe network, well, we need to figure out how to get that data and that information out of Civil 3D, into InfoWorks ICM.

Be on the lookout, existing networks, multiple barrel pipes, a little difficult to build in Civil 3D. I haven't met a lot of people that do that quite frequently. But multiple barrels for InfoWorks ICM is simply an attribute of, hey, we've got two. So you know how we marry a two-pipe arrangement between structure and structure to a single line within our single conduit in InfoWorks ICM, and then attribute it to is something to be looked for as an Autodesk product manager, a while ago, Part Builder and the Infrastructure Parts Editor.

Unique geometric shapes of pipes and structures, in many cases InfoWorks networks can accurately model the hydraulics within a unique shape structure and potentially even unique pipes. Part Builder I don't think has egg shape and horseshoe and things like that. So we've got to be careful in understanding the geometry of both our pipes, as well as our structures, and how that might impact our InfoWorks model.

And then inlet configurations, right? What is that restriction on our pipe network, whether it's a storm network, sealed, things like that, stuff that impact potentially the hydraulics in that. We don't exactly have a really good way of exporting out that you have a curb opening inlet, other than the fact that we potentially have a curb opening structure on Civil 3D. There's not really an easy way to get that attribute out, because that's stuck in Part Builder or the Infrastructure Part Editor.

But the vast majority of those cases, LandXML it's probably the quickest and safest way to export, say, a design network out, potentially, unless you're using, say, InfoDrainage. And in that case, InfoWorks ICM can read that InfoDrainage network like that.

But we also have something that is probably less common, Pipe Network. You can go to Prospector and select your nodes, right mouse click or selecting all of your elements, copy that to the clipboard, and paste that into Excel. And convert that either to a CSV or a Tab-formatted file, as data, and potentially manipulate that in a slightly different way.

Both ways are valid to get Civil 3D Pipe Networks out. I'm pretty sure I think on the forums, and there are use cases in which to take the Civil 3D pipe network, export that out to SDF, bring that SDF into Map 3D, Map 3D out to Shapefiles. It's a little bit roundabout way of doing it. I don't want to demonstrate that here in the presentation. But I did document that in the paper.

The big caveat there is, as I said with unique shapes, we do tend to leave a lot of the part catalog features and elements in the part catalog, so they don't seem to come along as well as other methods.

So as we do this, our Civil 3D pipe network, we have a pipe. So we can export this very easily from the Output tab, export that to LandXML. I like keeping mind LandXML files probably as clean as possible. So one grouping of elements, so then I know what will eventually show up in InfoWorks ICM if I have to do any edits and things like that, pretty easy.

Exporting it to Prospector, just a quick and easy ability. We can open Prospector. We can highlight all of these rows. Right mouse click, cope to clipboard, and then we can launch Microsoft Excel. And we can go ahead and paste this information right into Excel. Just kind of a thing to note is obviously Civil 3D enter height, enter width, enter diameter for all of our pipes all have the inch mark. Offsets and et cetera all have foot mark. InfoWorks ICM requires those to be actual numbers.

So you can probably watch me replace these. But we just need to strip that information out, turn these into actual numbers, and not text, and go from there. Let's go ahead and stop that video.

Back to the PowerPoint presentation. So for CAD Linework, right? This is probably the easiest concept to understand, but potentially the hardest one to actually demonstrate here, is InfoWorks ICM contains the ability to read a drawing file and convert objects, points, lines, polylines, 2D polylines, 3D polylines ultimately to a host of modeling elements.

So points can be nodes. They are either a junction and an outfall or a storage node. A storage node potentially is a pond. Junctions and outfalls are simply nodal elements, if you will, structures in Civil 3D pylons.

Lines, they're linear elements, right? River sections, conduits, there's a whole host of potential elements that can be there, including just general lines. The one nice thing about that lines component is we can actually take text that is on that same layer, and add that in essence as an either additional text in user-defined fields, or actually can represent the length of that pipe.

Polylines and all of the polylines one way or the other can be converted into some kind of area element, a zone, a 2D zone, a mesh zone, roughness zone, things like that. So very easy concept, maybe a little difficult until you begin to learn ICM on what shows up where. But it's just CAD Linework, so it's layer based. We'll go from there.

So the easiest way I could do that is just simply show you in a video with a simple model, simple conversion model. We can import or update from a drawing file any of these CAD elements. So I've got this short little conversion. It has a handful of elements in it, and a handful of layers. Because I didn't want to trouble you with a really long list of layers to select.

So as we select a layer, we can see the objects on that, that we can convert. We can convert points to nodes on the lines. We have one line. Let's go ahead and convert this to a conduit. Polylines, I have one polyline, so let's go ahead and select something like a 2D zone. It's an area element.

Let's do this. I don't remember which one I selected, yeah, base linear at 3D poly. Let's go ahead and select that as a roughness zone, right? Polylines are pretty much, I think a polyline could be open, a 2D or 3D poly typically are areas. But I made these all closed polys, and we'll convert length any text on any of those layers into length. We'll go ahead and just save this configuration.

So you can reuse this mapping, ultimately layer mapping to those elements. And you can mix and match those things. One nice thing about this, we took a conduit into the InfoWorks network, a line that didn't have two points on it, and we converted it to a conduit, added two points, and added the length to that.

Now, we have two networks, and I'll describe the differences a little bit later. But if we import that same file, and you begin to see a little bit of the difference, same CAD file, into a SWMM network, right? We have a little bit different set. We're still converting layers and objects. But we have different object results, if you will, if you go back.

So I will go ahead and do the same thing with the 2D zone. Oh, that's the conduit. This is the 2D zone. 2D poly, we'll convert that, those polylines to the base linear structure, and 3D poly, again to that roughness zone, right?

Nothing like finding a bug. This doesn't work into the SWMM network. So we'll go ahead and skip that and go on. So in Civil 3D, we have rivers. Now, rivers is not an object in Civil 3D. And it requires a secondary step. Is we have that surface, and I covered that, TIN surfaces and things like that. But you can actually build a HEC-RAS model from Civil 3D objects.

So there is a simple tool called Export to HEC-RAS. That will take your surface, your alignment, and your sample line groups-- and I would encourage you don't use the automatic tools for sample line grips. Hydraulic, cross-sections are not perpendicular to the alignment, right? But draw them. Create them from polylines, and you can go there.

Then obviously your bank lines, you can draw your bank lines in there. That will create a geo file that can be imported into HEC-RAS. And I think I'd prefer you probably use HEC-RAS 5 or earlier. I think 6, there's a slight tweak in something that has been going on there. Not sure yet, but 5 works. This was this tool was developed earlier than 5, but version 5 works just fine.

You'll have to open that, import that GIS, save that as a project file. Because the InfoWorks ICM is going to require a PRJ, and the geo file or the geometry file, not the geo file, so the converted version of that for import takes it a step further. Rivers obviously aren't something that is there. But the concept of a thalweg and a river stations kind of fits that alignment aspect. I've always said that rivers is just the upside down corridor that carries water, not cars.

All right. So let's go ahead and take a look at how this process goes. So this is a river flood example model that I converted the alignment to a thalweg, and converted those sections. So the Export to EC-RAS is the little button geo there on the lower left. So when we export this, it takes the surface, takes the reach alignment, takes the sample line groups, will apply a river name. So let's go with this AU demo. And I'll go ahead and select the left and right banks. We don't need them, but we can provide them if need be.

I'll go ahead and select. This is probably not the greatest left and right banks in that little meander, but we can export this to HEC-RAS which is a GIS import file into HEC-RAS 5. So we'll go ahead and save that.

And I'll save you the HEC-RAS import process, pretty simple in HEC-RAS. Create a new project, open the geometry, import the GIS. Save that into 5. So InfoWorks ICM can import that model, that HEC-RAS network model pretty simply. We can go ahead and grab that PRJ file, and the G01 file pretty quickly. We can import that into InfoWorks ICM pretty quickly.

So that's our rivers. Advance that. So let's talk about InfoWorks ICM. How do we take all that information that we have exported, or maybe have sitting beside the model, and import that into InfoWorks ICM?

So for ground models, surfaces in Civil 3D, InfoWorks ICM can accept both ground models in a raster or TIN format. So really that first question that I suggested that you ask yourself in your project, where is the source data coming from, right? Is it LiDAR, remote sensing, is it a point cloud, uniform, some kind of raster TIF if you will? Right?

That makes it easy to import that as a ground model grid. It's a grid. Boom, done. I won't have to worry about Civil 3D. Civil 3D can consume that same grid into a TIN. Works better for other design elements and things like that, than thinking of your grid surface and Civil 3D as a Minecraft project. But most people on projects typically are dealing with TINs, Triangular Irregular Networks, TINs.

Maybe that comes from a terrestrial survey, points, survey database, however you build your TIN surfaces. LandXML is a key tool here. So we can import a LandXML file and get a ground model TIN out.

InfoWorks ICM and one of the things that the InfoWorks network contains is the ability to do inferencing. So that is the ability to take missing information, say, you've collected survey points. You didn't get ground elevations, but you've got inverts. So you can import that coordinate system and do that. Take the surface, and take the ground level off of that. And we can do an inference, right? We can populate some of that data in the model and tag that as an inference. And we'll talk about tags in a little bit.

So let's go ahead and show you-- it's pretty simple InfoWorks network, ground model TIN, grand model TIN. Obviously. There are a number of ways-- arc info, ground model, 12D model. In this case, I'm pulling in a Civil 3D surface that I just exported, and I can import that surface or the multitude of surfaces. I'm going to check our units. I'm in the US. So I'm going to use feet, Imperial units. We can see that here.

And I can actually create an InfoWorks network. I'm just going to drag that surface in. I'm going to zoom to that ground model. Boom. There's the simple example network. And we have that available. Now we can actually go ahead and import or create a new TIN, ground model TIN. Let me see if I can make sure that I stop this video here.

Right here is when we create a new TIN, we can begin to merge various data sources together to create a new TIN model. So you can kind of see that we can take an InfoWorks network. We can take network objects, polygons. We can exclude polygons. We can take a grid and a TIN, kind of begin to merge those things. But we can then add additional data together.

I know this is Autodesk University. But LandXML files are an element in which Civil 3D exports are points and triangles, perfectly good. So you can just import that directly. But let's just say you don't have-- because various packages outside of Civil 3D can speak LandXML. One of those is Bentley. They can actually export just the break lines and the definition.

So you can actually build a TIN file from break lines, or data points and contours, because there are a number of different ways to define a surface within a LandXML file. I wanted you to be aware of those.

You can also see that text files, as well as shape files, can be used to create a TIN surface. So there's a number of different ways to build a TIN surface in InfoWorks ICM. I'm going to continue to play this video. But I'm not going to show you either of those here. But I just wanted to make sure that you were aware, because occasionally if you were to do the import, and you didn't have triangles in that, the import would not work.

So on a grid surface, let's go ahead and import a grid surface. It'll take primarily a whole bunch of grid files. In this case, we're going to grab an ASC file. We can convert things back and forth. You'll notice that the surface is a separate object. It doesn't go into the network. We can zoom in, and zoom out. We have this. We can display it. We can clear it from the network. So we can use it. It allows you to swap out, if you will, what surface you're using, great for projects.

Nothing like a little Camtasia going on there. So let's talk about pipe networks, now that we've talked about surface. Two primary pipe network types, an InfoWorks network and a SWMM network.

From a manhole perspective, we have two elements. So the InfoWorks network contains a lot more information. It contains a lot of information, especially about structures. InfoWorks, it's built out of our UK office. A lot of the Public Utilities there, I mean England is old. So, we've got a lot of very unique structures where they actually want to look at the chamber, and the shaft, and the areas in there, pretty complex.

SWMM networks, if you are somewhat knowledgeable about what a SWMM network is, SWMM networks are pretty much four foot round diameter structures. It's the assumed element. If you don't want something like that you use a storage node to represent the volume stored in that structure.

So there's a lot of information there. Some stuff is default. But understanding what a structure is, especially comparing that to the Civil 3D structure and the information that we can pull out of Civil 3D, we have to begin to understand a little bit of that differences.

The actual conduits or pipes in these structures, again, do contain different values. So we need to really begin to understand what network are we going to be using, what elements will come. I think if you look at the InfoWorks network, and you have some knowledge of what a pipe or conduit in Civil 3D is, there's going to be a lot of missing information in that InfoWorks network, right?

SWMM network's a little bit more forgiving. They do have a lot of use. Think about what Autodesk has currently in its portfolio. Getting it to Autodesk Storm and Sanitary Analysis, there's a lot more commonality in that pipe network there. Innovyze has got a long history with the SWMM network, whether it's XPSWMM or InfoSWMM. SWMM Networks in InfoWorks ICM seems to be the next generation. But understanding this network schema is a key element of migrating that pipe network from Civil 3D to InfoWorks ICM.

There you go. So one element that I want everybody to be aware of, and this is something that the SWMM network, we have a link ID. And those link IDs have to be, unfortunately with SWMM, spaces got to be unique. The key is that link ID. And InfoWorks networks, ultimately it's the upstream node ID, not the name. So you've got to be aware of that difference in the schema. But we'll see that a little clearer here in the next slide.

So if InfoWorks networks, well InfoWorks primarily interfaces with data using the Open Data Import Center or OIDC for short. There is an ODEC-- I can't say that easily enough. But it's the export center that allows us to return data. We'll cover that in a couple of slides. In this case, the OIDC allows InfoWorks ICM to import data from a variety of different formats, whether it is Shapefile, CSV, or other GIS formats.

These object fields can import and correspond to the various network type, based on what we saw in the prior slide. As I said, keep an eye on that primary object key, right? The upstream node ID is a required key for InfoWorks networks. So this semi-precludes an immediate direct import from Civil 3D, because that logic isn't exactly exported directly today. It requires some effort.

I can build a table that will contain that information, but I can't export that table. So it's going to require a little bit of effort, if we want to go directly into an InfoWorks network. Don't fret. The SWMM network, which is a little bit more user friendly, if you will, into Civil 3D, we can actually import that SWMM network right into the InfoWorks network. So it's a couple of steps, and not too bad.

A couple of slides ago we showed a little video of exporting copy to clipboard out to a CSV file, removing our inch and foot marks. We can import those into ICM pretty quickly if you're doing Tab separated or CSV, importing that into SWMM network, and then converting that over into InfoWorks, right?

Obviously, model imports which you saw on the river are also possible. So one could use the SWMM network to import data from which the users then can migrate SWMM networks directly into InfoWorks. So it just happened to be a user of SSA. You can import that, take SSA, export that to a SWMM network, and import.

So the edit in SSA is a possible route to get your Civil 3D pipe network into InfoWorks. Again, a little bit roundabout way, still there. But you could be potentially using other SWMM network, including EPA SWMM to generate those, and deal with that. It's possible. SWMM network also does allow LandXML import directly.

So if you go back to the export of the pipe network from Civil 3D, SWMM network allows you to import that model directly into a SWMM network, which then can be converted into an InfoWorks network. A couple of steps, but shouldn't be too bad.

SWMM networks also has an Open Data Import Center. Again, node ID, link ID, that's very much the Civil 3D model. So, it's a little bit more friendly right from that unique-- Civil 3D remains that node-link model. So, it shares the most in common with the SWMM network.

Again, as I said with the pipe networks, understanding the schema and what maps to what is a key element. But be sure to pay attention to units behavior. InfoWorks ICM stores everything in its database as metric. So if you're working in Imperial, if we're to use the Autodesk parlance, feet, then make sure your system is set, or your units are set to user which is in feet, I almost one kind of play the Imperial March from Star Wars. But I'm not going hum it.

Too fast there.

As I said, importing a model, importing a model from other Hydraulic networks is easy we saw it on the HEC-RAS network to be able to import that really quickly. We've also mentioned the SWMM 5 text file. You can import that Storm and Sanitary INP export of Storm and Sanitary, and import that into a SWMM network very easily. If you happen to use InfoDrainage and have InfoDrainage Ultimate from Autodesk, InfoDrainage is at the top. So you can supplement, a say, watershed size with a project from InfoDrainage.

MicroDrainage, another Innovyze product, is readily used in the UK for UK customers and clients. It really never took off here in the States. But MicroDrainage is another one of those projects. XPRAFTS is primarily Australian hydrology. So for those of you in the US, think of it as kind of a HEC-1 type model here in the States. But it is a hydrology, a runoff model that has some basic hydraulics, things like that, some routing type elements.

But you have SWMM 4, you have SWMM 5, you have TUFLOW, you have SWMM networks, and you even have XPSWMM which is another Innovyze product. So we can take all of these models, convert them into InfoWorks models to supplement your design.

Let's look at this, again, simple model. We'll just go ahead and import from SWMM network. We'll do that conversion, grab that SWMM network, and very quickly get my SWMM network, in this case containing a mesh, containing all of my elements, roughness polygons, and so on, and so forth. We'll watch that again. I've got this on a loop, because it's a really short video, really easy to convert all of those objects from one to the other.

So as I said, you saw a quick preview on the HEC-RAS import. I forgot to cut that video out. But we'll go ahead and redo this, because I do show a little bit more in this version. So we'll go ahead and import that RAS5 file, same demo project, same G file. We look at this, and this is a river section, a river alignment. And we'll go ahead and note that those cross sections that-- let me back that up. Go back to the section. This section was cut in Civil 3D.

So that surface is not here, but that sample line group cut that section, imported all of those. We don't have roughnesses, but we can add that into InfoWorks, pretty simple way to get river sections in. Now, just a quick note, InfoWorks ICM is a non prysmoidal. So that surface is a key element. It will do some additional sampling along that profile.

OK, escape that and advance.

So let's talk scenarios, scenarios, collaboration. We want to be able to actually begin to optioneer and help solve probably in the best case scenario potential solutions. So how do we collaborate as a team? We need Workgroup Server. This is available from Autodesk today. I'd show you a screenshot, but it's not all enabled yet at the moment. We're working on that.

But typically, it gets installed on a server within the local company, so your team of modelers can collaborate. I install it on my laptop. That's why the server name is called local host. I can create that, save those files, check them in here. But that provides us that ability to ultimately allow multiple users in a versioning system. Everybody can work on a model. Unfortunately, this is a sample of a Commit history from one person on a project.

But over a number of times, you can see what they changed, allows you to have comments. Right and you can do Diffs. You can look at the details. You can branch from a certain point in time, and be able to do various things. A lot of very interesting abilities occur when you have this type of environment. This is very much, if you know anything about software development, using Git and things like that. So pretty neat to have that ability to have a Commit history, especially when building a model.

There's thousands of elements, and you can have very large 1D/2D models, 1D catchment models. I don't remember why. Why is the rim three feet above such and such. It gives you the ability whether that came from an inference, an old inference, and things like that. We can have those. We can define those flags. So we can begin to know where it came from, what the provenance if you will, of that data is in our InfoWorks model.

Is that the demo? Is that the Autodesk University demo? Did I make that, or was it someone else that made those changes? And we can look at those, and we can filter, and find, and understand who goofed up. I'm just kidding. Ultimately who made those elements, who put those in, so we can talk to them and find out why was that scenario built. What were you thinking when you tried to run that option? Because when you begin to look at lots of options, it's good to understand the thinking that went into creating those, especially if you're resurrecting or re-looking at a model.

Well, collaboration is one thing. Scenarios and optioneering is primarily another. We actually want to take our physical network, and hopefully as an engineer, test potential solutions. My options aren't super elaborate here that I'm showing, single pipe, size x, size y. It's bigger, smaller, or whatever. Don't let my simplicity here fool you in understanding what could be done with scenarios. But in many cases, we can begin to build a lot of what-ifs, all kinds of other options that could be brought about and incorporated into our model.

When we get into simulations, we can take that model and those scenarios, and we can apply a range of events. In this case, I've got one 6-hour Huff first quartile, Illinois Northeast rainfall event. Don't use my limitation here in trying to show you what's possible and say we can only run one storm at a time. We don't. Can have multiple storms, multiple events.

I will say in the UK, they run a number of durations and events. Illinois, I was always frequently using Huff quartiles, and doing critical duration analysis, so running multiple storms to determine what the worst case scenario was. I will say in Australia, with Australian rainfall and runoff, they take it probably one step farther than those Huff quartiles or Bolton 75 quartiles do, and take it into a giant set of thousands of potentials, especially on the watershed scale size.

Running all of those things takes a lot of computational power, and InfoWorks ICM is quite capable of running all of those storms, aggregating and identifying what's the mean, what's the max, what's the worst case scenario, where we can take all of our scenarios, all of our runs. The green there is ultimately two scenarios, trying to keep it simple. The quartile 1 and then another run with the same quartile run, just with bigger pipes.

But we can run all of these things all together, take a set of simulation results, and look at and identify from a hydraulic performance perspective, what's the best option. That's ultimately what we're trying to do is take those scenarios, the blue there is indicating that they're both running when I took the screenshot. But once those are done, we can then compare them, identify what is the best solution from a hydraulic perspective or a flooding perspective. Take those results, and then begin to export.

So how do we do that? How do we get that information out? How do we pull those results back into Civil 3D?

From a network. From s 1D perspective, again that ODEC, the Open Data Export Center, very similar, just the reverse of the Open Data Import Center, Shapefiles, CSV files, however we want. Always check your units. To use it with Civil 3D, the important GIS data, which is a Shapefile and folder, the limitation with that import GIS isn't going to give us the ability to update a network. We almost have to potentially recreate that network, erase and recreate, not the greatest workflow.

So we're going have to work something out with the Civil infrastructure team. What's the best way to roundtrip that data, especially coming out with results? Some of the manual export to GIS, the results information is just the physical results on a node. So you might need to then-- I mean if you're pretty good at Map 3D or other GIS formats, begin to do a table join, so that you have physical network, network results together in Shapefile format, and use import GIS data to do that.

I'm not going to show you that, pretty easy. I'm going to back up one here, back up, not forward. The other thing, the important GIS data, and I think I did mention it. But I'll reiterate it again. It creates a new network. So it'll increment a network. So if you imported or you have a network called network 1, the next time you use the import data, import GIS data after you've mapped everything, which is again it's not potentially an easy thing to do, you can save all that mapping. But it'll create that as network 1(2). It will make a copy of that network. And then you're into the Civil 3D devices to figure out which one to keep, which one to delete, and go from there.

So we need to figure that workflow out a little bit better. And hopefully, I've seen a couple of potential prototypes, help us do that a little bit easier.

How do we push results back in? So InfoWorks ICM is pretty powerful. When we deal with flooding, we're primarily dealing with flooding extents. It's almost a spatial request. Where does the floodplain end? Where am I safe to build, if I'm putting a house.

With many models' abilities today, the spatial context no longer just limited to that sample line, if you will, or that cross section line. But we can get a full set of spatial results. Back when I practiced, that HEC-RAS model, I was putting those cross sections, applying that 100-year flood plane, that 50, and building surfaces from those locations, and trying to figure out how to triangulate between two cross sections in Civil 3D to allow my water surface elevation to be cut in that gap, if you will, between where I cut my cross sections.

I don't have to do that anymore. ICM provides a full spatial result on the 2D mesh. I wish I had this in practice many years ago. But with the advent of HEC-RAS 2D, with the speed in which Innovyze has added 2D results, whether it's XPSWMM or InfoWorks ICM, and the pickup of that, a lot of that comes through development in Australia, which suffered a lot of really devastating flooding a number of years ago. They really took towards the advent or the adoption, of you will, of 2D mapping.

2D mapping provides you spatially a lot more information about risk. Risk, how deep does it get? How fast might it be? Something that might sweep you off your feet, and beginning to understand all that. There's a really nice highly colorized Civil 3D drawing file on the output. That is, in my opinion, visually stunning. It helps communicate that risk. Obviously, you have to print sucker out in color. But that's the Civil 3D surface of depths, flooding depths, if you will, within a subdivision.