Missing Hydraulic Prototypes [ORD 2018R4]

Steve:  This is a deficiency in the software which creates great challenges for many.  I reported this for enhancement some months ago.

Here's what happens:

1. You, like most of us, need to separate feature definitions into existing and proposed libraries. In other places, they need to go a step farther and separate sanitary from drainage as well as existing from proposed, resulting in the need to define FD in four or more libraries.
2. However, hydraulic definitions can only come from one place, which is the file defined in SUDA_Hydraulic_Seed. Part of the hydraulic definitions are the prototypes.
3. Thus, when you start a project, your existing prototypes from the existing library never get populated into the project DGN and voila you are jammed up.

The only workaround I have found to date is to make a special seed file for utilities where the necessary prototypes are pre-populated. This is not a trivial task and must be redone from time to time to keep the seed in synch with the library.

On a more technical note: The OpenRoads drainage and utilities tools are a merger of openroads and Haestad technology. This merger is not trivial and was anticipated to take multiple years.  Some of the last vestiges of the items not merged are the hydraulic properties and settings which still live in a 100% Haestad context.  Once these cross the threshold and become native (for OpenRoads) properties then these challenges go away.  For example, one of the items which exist in your conduit prototypes is roughness coefficient. This needs to become a native property of the feature definition rather than a pointer from the FD to a prototype.  This is a pretty heavy lift for the Bentley development team. 

A year old thread, shows up in my search about Hydraulic Prototypes with a response literally hours old! What are the odds. And not only that, but it answered my question spot on!

There are no technological risks to your plan. This whole area of conversation is just administrative challenges.  If there is only one admin then having a single file is convenient for maintenance. But when the work load needs to be spread around then multiple files are handy.  Where things become a real problem is when the administration of the files is dispersed to multiple groups within an organization which are only minimally connected to one another. 

Example: an organization I know is only loosely connected between units of the organization. The utilities ggroup (think sanitary sewer) is very separate from the hydraulics unit (drainage design).  Both groups maintain independent libraries yet both groups need hydraulic design capability, ie a single SUDA seed.  

The solution is simple right? Just put the sanitary stuff into the hydraulic library which is my standard practice.  But that solution assumes that one group will cede or share ownership of the library with the other group.  See what I mean about being an admin problem rather than a tech problem. 

Robert:

Thank you so much (once again) for your thoughtful approach to this issue. The good news for us is that we are small enough not to have to deal much with the administrative challenges you have put forth. I have developed all which we have- so far- as regards ORD in situ. All CAD/ CADD/ software issues/ changes go through me as a single point of "knowledge" (LOL).As well, all of our libraries are also supported/ maintained by myself, and all information is at a common network location. 

I do have- yet another- question for you, however: The program defaults to C:\ProgramData\Bentley\SUDA\10\ for the Conduit and Inlet Catalog (amongst other XML's). I have been trying to track down the configuration variable which points to this location such that I can store this information at a common network repository. Do you happen to know the name of this variable? 

Thanks so much for your knowledge and your support within this community!

Have a great weekend!

Mark

Mark: Those XML files are mostly irrelevant, which is good because there is not config variable as far as I know.

Specifically for the conduit and inlet XML files you mention, these are not used in the day-to-day course of business. The catalogs which are consumed day by day are contained in the dgnlib file.  The XMLs are really only useful in the OpenRoads/SUDA sense for a transport mechanism (export/import) between files.

So, why are they there? These XML files are part of the Haestad (OpenFlows) engine which are used in a much greater role when running Openflows products (StormCAD and the like) in a standalone configuration.

There are other XML files besides the catalogs, in the location you describe and elsewhere, which have a more active role day to day. In the queries and flex tables for example, you will see three categories 1) Project 2)Shared 3) predefined.  The shared and predefined lists can be configured inside of the openroads environment but to roll them out to an organziation requires distributing the underlying XML. I have not found an elegant way of doing this, so I have always recommended store the organization standards in the SUDA seed under Project, ignore the Shared category and use the Predefined fr whatever they are worth.

Robert:

Thank you so much in the information which you have provided here.

I have set up our SUDA dgnlib with the variable "SUDA_USE_HAESTAD_CONDUIT= 1". Such- I believe- forces the program to use the XML files rather than the predefined values when this variable is set to "0". I am assuming- now- that you have defined the variable to "0" and have modified the tables to use those- as would now be stored- in the dgnlib? I believe that I have made an inquiry to such in a previous post, but I would really like to better understand how YOU have your dgnlib set up. Better to learn from those who have gone before me in all of this development!

Mark

I use the same variable.  But it does not use the XML files.  The conduit library is actually embedded into the DGN file.

I use the same variable.  But it does not use the XML files.  The conduit library is actually embedded into the DGN file.

Robert:

Weird... indeed, my assumption that the XML's were being used for SUDA_USE_HAESTAD_CONDUIT= 1 was incorrect.

I removed both the conduit catalog and the inlet catalog which I created from the C:\ProgramData\Bentley\SUDA\10\Libraries\ directory, and the information still shows up within the dgnlib. In fact, all catalog information shows up perfectly fine when creating a SUDA project within a new dgn file. So, it appears to me that all needed conduit and inlet information catalogs are indeed embedded within the dgnlib for use by our team as all libraries are shared resources. 

One can learn much from discussing these things with the experts!

Best Regards,

Mark