Civil 3D - Feedback for Dave

[fcernst]

Dave Simeone wrote: "Hi folks

We’re interested in hearing any and all feedback on QTO or any other feature so that we can target future improvements that will make the most positive difference."

The new Civil 3D 2014 release has been characterized as “underwhelming” by the users in this group. This due to the lack of progress in implementing efficient design workflows, combined with the conspicuous lack of new features.

The perception is that Civil 3D management has lost its way, or is simply not capable of finding its way in this regard. It appears Dave either 1) does not listen to his professional engineer (PE) advisers, or 2) his professional engineer advisers are simply giving poor advice, and not bringing good ideas and workflow concepts to the table for Dave to consider.

The following are ideas to help make our Civil 3D design workflows better and much more efficient:

Engineering Design Workflow:

We need the storm drainage hydrologic and hydraulic analysis and computational tools to be placed back into the Model space environment so that we may interact directly with our digital terrain models.

Grading and drainage design is an intimately paired iterative process. To be effective and efficient, the two processes need to reside together in Model space.

The current Import/Export storm drainage analysis paradigm is horribly frustrating for engineers and designers. It was an inexpensive (cheap) way to go. Just slap it on…

I get offline emails from engineering firms telling me that they are realizing now that this is creating a severe bottleneck in their production, and they are wondering what we are doing to manage.

Solution:

We need to be able to physically select inlet inverts and culvert inverts directly off the model for analysis and have the data go straight into the hydraulic calculators. We had this interactive capability in LDD.

We need to be able to directly connect our tributary basins (Catchments) to our inlets, culverts and pipe networks.

We desperately need HEC 22 Method HGL/EGL calculation capabilities within our Pipe Network models, within the C3D Model space environment.

We need to be able to develop stage-storage-discharge curves directly from the grading design reflected in our proposed surface models.

We need to be able to develop and test multi-stage pond outlet control structures directly in Model space.

Hydrology Methods we need in model space for Site Development and Highway drainage design:

• Rational Method
• FAA Modified Rational Method
• SCS (TR 20 and TR 55 Methods)
• Hydraulic Calculators and Methods we need in Model space:
• HEC 22 Method HGL/EGL calculations Tab in the Pipe Network editor.
• Multi-Stage Pond Outlet Control structure calculator.
• HDS 5 (HY8) Culvert Calculator
• Standard Step water surface channel calculator
• Open channel flow calculator (Mannings)
• Orifice calculators
• Weir calculators

Corridors:

Correct grading off a Transition:

We need correct orthogonal link projections to correctly create a TIN product across our curb and gutter, sidewalk and ditches when they are dependent on a transitioning alignment, feature line or polyline. The current workaround is to force the End User to go to the extra effort of creating an Offset Assembly. Offset assemblies require an additional Alignment and Profile. All of this has to be done by the designer solely for the purpose to realize the correct link projection orientations and subsequent correct TIN development.

Dynamic Alignments and Profiles:

We need dynamic alignments and profiles. When we adjust a ditch profile and hold the ditch Foreslope constant, the ditch moves out accordingly. We need the ditch alignment to dynamically move out with it and update the profile. The software currently does not do this. We have to do it by hand.

I mentioned this before in the forum, and somebody replied that he wasn’t sure you could do it. He mentioned “I think it’s a tiger chasing its tail”. He was referring to creating a circular reference.

Programmers however know this is easily handled with an iterative loop statement and a convergence tolerance. Excel for example, allows you to set a convergence tolerance when you set two equations equal to each other. This is the exact same principle.

Split Regions:

When we spilt a Region, say for a bridge, and purposely leave the resultant space vacant of any Corridor data, the Corridor Surface should respect that, and not triangulate across the gap. This would also save us from having to go to the extra effort of creating and implementing a Gap in our Material calculations that is also not dynamic!

Immediately repair the defective QTO program. This is a serious management debacle and oversight. This is classified as a known issue from Autodesk that has frustrated users for 4 years the record shows, however management has chosen not to address.

Corridor Shrinkwrap Boundary:

Drastically improve the performance and consistency of this routine.

Daylight Cleanup:

We need Corridors to be aware of their neighbor Corridors and cleanup the intersecting daylight grading between them.

Street Capacity:

We need the Corridor object to compute cross sectional street storm flow capacity so we can adjust the street design and add inlets where needed in an iterative process. For example, the typical street capacity criteria are:

Minor Storm Event: No curb overtopping allowed

Major Storm Event: Depths of 12”-18” over gutter flowline are typically allowed. Flow not to encroach past ROW.

Buildings to be protected with the storm drainage design by providing 1.0 of minimum freeboard.

This is truly an iterative design process. In this design and analysis process, the design engineer is  required to adjust the Catchment Area that is tributary to the street, to determine the point where street capacity criteria would be exceeded, the place an inlet at that location to take runoff from the street. Then proceed down the Corridor (street), start a new Catchment that is tributary to the street, and so on, and so on.

This is why we need the drainage tools in Model space! We need to be able to add inlets and storm sewer to the Pipe Network through this design process, and concurrently perform the inlet sizing and storm sewer sizing (HEC 22 Method HGL/EGL analysis) in the Pipe Network editor.

Subassemblies:

Take heed to the vision Peter Funk describes in his video regarding subassemblies. Peter describes how we currently have way too many subassemblies, and should consolidate that down to about 5 very efficient and capable subassemblies to be offered on the Palette.

SAC:

Bring SAC into the C3D Model space environment for debugging purposes. This is another awkward and time consuming Import/Export paradigm implementation.

Add additional logic Flow Control Statements

Do While (While) loop – Really need this control for reaching out incrementally to test conditions, like the distance below EG.

Case Statement – Really need this to relieve us from our current parenthetical jungle of IF statements.

SSA:

I have submitted support requests only to find that they are “known issues” that have spanned over at least two new software releases. This is totally unacceptable.

SSA is marketed to be a hydraulically dynamic capable model that can implement the full St Venant equations. One of the typical reasons we turn to a hydraulically dynamic capable model, such as EPA SWMM 5, is to model dual drainage systems.  Dual drainage is the modeling of the storm sewer system and the street system together during the Major storm event when the storm sewer system is taxed beyond capacity, thus surcharging and flooding on to the street. Flows can reverse, and go back and forth between the underground storm sewer system, and the above ground street system.

SSA is marketed as having this capability, even showing colorful diagrams, of dual drainage analysis, when it clearly doesn’t.

The diagram below from the SSA help depicts dual drainage analysis, they are calling it the “upwelling” flow you can see coming up from the storm sewer pipe and out the inlet, on to the street system. However, the software fails in testing for this capability.

Quality Control Management:

The perception is that Dave lets the Civil 3D software fly out the door without implementing appropriate quality control (QC) management procedures. This perception has lingered since 2004.

The perception is that Dave relies on End Users to do the debugging for him. The perception is he understands that junior engineers and designers are the most effective and eager to please problem solvers around, and he is taking full advantage. Many of us have spent countless hours of our own time debugging issues for Dave. The perception is Dave relies on these people to flush out the issues for him at essentially no cost to his department’s budget.

The lack of Civil 3D quality control is wholly unfair to the design staff of our engineering firms. The debugging and reporting  time that is required due to the lack of Civil 3D quality control, directly affects our project variances (profit) and staff morale.

In the case of the extremely unstable initial Civil 3D 2013 release last year, staff engineers and designers struggled with the crashing and instability problems for virtually the entire year, until a service pack was released deep in to November.

This was after we as End Users flushed out the all the issues and debugged the software for Dave, having to provide detailed step by step information as he demands we do.

The “step by step’ requests from Autodesk have to stop. This should change to where we simply notify Autodesk Support that we have found a problem. Invest some money into your troubleshooting staff and their procedures. Autodesk Support tells me they have no other diagnostic tools for the software than what we have as Users. Shame on Dave for this!

Take the second QTO problem where its formulas do not currently do simple math correctly. I simply stated that to Support.

However, they asked me if I could take the time to do a video to essentially just show them the math!   Unacceptable!

[Anonymous]

There is a way to get the large watershed delineations in C3D. I was just educated.

[fcernst]

"delineate watershed for the point at existing bridge"

By clicking on the desired discharge point as you requested? Please share.

Are you talking about the Shrink Wrap workflow perhaps? 

[fcernst]

The Civil 3D Help needs a thorough Review and Edit. It is extremely poorly written.

I see the problem I show below in many instances in the Help. 

Note all the "W2", "W3", etc. dimensions drawn in the figure. After the figure, throughout the entire Help for this subassembly, there is not one reference defining these dimensions!

A figure in a technical manual or reference should never contain variables, dimensions, etc. that are not subsequently referenced in the text.

I ask that you and your staff sit down and go through this subassembly reference manual and do two things:

1) Review the Help for content and technical accuracy relating to each subassembly.

2) Test the subassembly performance at run-time in Civil 3D for technical accuracy, and ensure that the Help and the performance of the subassembly directly correlate.

I have tested a relatively small sample set of subassemblies, just through project work mostly,  and have found an unacceptably large amount of Confirmed Defects with the subassemblies,  just within this very small sample size.

[mathewkol]

Which subassembly in particular has the W1, W2 stuff? I'd like to take a look at it.

[Anonymous]

if you haven't seen this elsewhere already: watershed delineation.  Not as slick as ESRI ArcGIS where you can pick your discharge point and it works, but has sufficed for what I am doing.  Am working on a parish wide bridge to culvert project where large watersheds (ex. 1200 acres)  exist.  I get a nice watershed most of the time by first building a surface from dem, extracting the contours, creating a new surface using a polyline data clip boundary (yes, unfortunately I have to figure out the basin by contours), create a surface style for the watershed, create a watershed in the surface properties analysis tab and merge adjacent boundaries by 1.0 to 4.0.  Most of the time it works pretty well. It's a bit of work, but hopefully the create catchments by picking discharge point will be fixed.

[fcernst]

The title is shown at the top of the image I provided. It's the MedianDepressedShoulderExt.

[mathewkol]

Ah yes, didn't see that while looking at it on my BB.

[mathewkol]

Indeed, it could be a little more obvious what those mean.

[sboon]

If I recall correctly the Help files used to include a link on each page that could be used to comment and report any errors in that page.  It was a useful feature, but I can't find any way to do it in the current version.

Steve
Please use the Accept as Solution or Kudo buttons when appropriate

[lazicr]

Fred,

Subassembly Composer provides plenty of functionality to satisfy the most demanding uses of corridor technology.

I strongly recommend you checking that out and considering to develop your own content that will meet your exact needs for anything subassembly related.

In my honest oppinion, I'd take a new functionality such as SAC any day over having to rely on someone else's schedule, resources, QA and engineering acumen to deliver to MY projects, what MY projects need.

Just the thought.

Best regards,

Rad

[fcernst]

Now what in blazes makes you think I haven't?

My most recent SAC application was inspired by my recent confirmation (posted here) with Autodesk development, of defects in both the DaylightBasin and DaylightBasin2 stock subassemblies.

I have developed a control subassembly in SAC that transmits output parameters to be passed to other stock subassemblies to compensate for yet another setback, while these get fixed in development.

It took away billable time again that I shouldn't have had to sacrifice in the first place.

There was a transportation engineer that commented awhile back that essentially said "we are not the programmers and we shouldn't be tasked with this responsibility", and the subassemblies, like the Rehab subassemblies to be specific,  should be in working order when delivered to us by Autodesk.

Having said all this... I think SAC is a great software implementation.

[lazicr]

I think we have a different type of attitude towards developing project specific custom content.

I hope however, that we can agree about creating a subassembly that will be all things to all projects is impossible. Even if we limit it to a daylight, median ditch or an overlay function.

Or, a curb and gutter for that matter!

So I think we should forget about the stock subassemblies, really. They are good for teaching kids how to design roads, demo jocks to spin in Object Viewer and that's about it.

When you need to do a real world work on a real project - make your own and be 100% confident with the output (like you have done obviously).

I don't know if you've ever spoken with a veteran user of MX Roads or InRoads/GEOPAK?

They are the crowd most proud, protective and praising of "THE CODE" that, through hard work and extensive mental self-improvement, eventually allows them to do just what we can do with SAC while playing on screen with those icons, rectangles and diamond shapes...

And, they have preached "THE CODE" as the most determining and differentiating feature of superior highway design package for about, 30 years, right?

Happy coding!

Reagrds,

Rad

[Cadguru42]

---

@lazicr wrote:

I think we have a different type of attitude towards developing project specific custom content.

I hope however, that we can agree about creating a subassembly that will be all things to all projects is impossible. Even if we limit it to a daylight, median ditch or an overlay function.

Or, a curb and gutter for that matter!

So I think we should forget about the stock subassemblies, really. They are good for teaching kids how to design roads, demo jocks to spin in Object Viewer and that's about it.

When you need to do a real world work on a real project - make your own and be 100% confident with the output (like you have done obviously).

I don't know if you've ever spoken with a veteran user of MX Roads or InRoads/GEOPAK?

They are the crowd most proud, protective and praising of "THE CODE" that, through hard work and extensive mental self-improvement, eventually allows them to do just what we can do with SAC while playing on screen with those icons, rectangles and diamond shapes...

And, they have preached "THE CODE" as the most determining and differentiating feature of superior highway design package for about, 30 years, right?

Happy coding!

Reagrds,

Rad

---

So you think only kids use the built in subassemblies? You think everyone should make their own subassemblies for every project? In what world does that make sense? Besides being ridiculous, Autodesk has marketed Civil 3D as being able to do these things without customization. 

[kenneth238]

nice!

[MikeEvansUK]

Dave, specifically on QTO and not digressing;

One Big improvement is that this information  from QTO is NOT included in the NWC export files. Perform a DWFx export and you get the information but from memory just the code. Obviously this now should have the option to add as object parameters directly after a analysis and include all information (selectable?).

It would be very beneficial to be able to use part specific parameters (contexts) / object parameters in the computations. I'll give an example,

Structures.

We can currently calculate the depth etc however what we would really be interested in is the overall area of dig necessary to install the item.

Obviously some of this is hard-wired but I'll be specific in calculations for correctness. words in Bold are variable numbers that I would fix to my model ( context parameters) each different due to circumstance, changed in each structure as needed.

I calculate this width w1 as the Internal Diameter + (Wall thickness + surround*2).

Now using the depth d1 ((CoverLevel - Invert of lowest Pipe - SumpDepth - BaseThickness + Subbase )

And a bit of maths we can approximate the overall construction dig. : (WorkingSpace)2 + (B1)2 + (W1+D1) = Approximate overall dig needed.

The parameter Workingspace is the additional space needed for construction, Base Thickness would vary depending on the size of pipe, Subbase depending on the subsoil /CBR ratio.

We would want to know the number of PCC rings or the quantity of brickwork needed, so many other things accounted for (I have changeable interactive Brickwork heights for the riser in my PK models).

We also want to know the same quantity of dig from existing ground which is not available in the structure unless we do this twice.

Pipes.

Approximate area of dig;

As above with additional widths for trenches and calculated from the cover at start, end and mid ordinates along the pipeline.

Parcels,

I use a simple calc to work out areas of surfacing based on A*depth of material However, it would be nice to tie this together with gradients so you can take off the subbase which may lay at a different gradient to the top surfaces. An implicit volume can be sought from design however for approximation we could use some more maths.

The report could also be used to Check design standards in the pipe model, Depth to crown vs structure size, Max pipe Diameter Vs Structure diameter & type of structure (PVC / Concrete).

I have written a program to do this myself but it could be easier.

These are just few ideas which spring to mind and I hope they help make improvements or give some pointers.

I'm sure others will add more specific details for ideas in due course. Perhaps you could also speak to the Navisworks Team as their tools are really geared towards Revit exports and don't include multiple lengths / widths or height values (walls generally are not differing in heights).

Thanks & Regards.

Mike