ORD SUDA - Prototypes - Please don't make assumptions

OK. Now, an inconvenience has become a trial. A little background:  My client is very decentralized.  The drainage group and utilities group are very nearly autonomous. They have separate SUDA libraries. Drainage is in one. Existing utilities are in a second and proposed utilities are in a 3rd.  Yes,the 2nd and 3rd libraries could be combined, perhaps they will.

You will note that prototypes are only loaded from a single library and only from the active DGN/DGNLIB. So, in the utilities library, I cannot utilize the drainage prototypes, even though I only need a dummy.  

I work for the utilities group which includes sanitary sewer. Easy enough for me to add dummy prototypes, right? Wrong. If I add a prototype in the utilities library, it can be assigned while I am editing the library but is never available in the project, because it never exists in the project because it never existed in the hydraulic seed. I cannot trick it by making a prototype with the same name as one in the drainage library because the prototypes are keyed off a GUID, not by name.

Also, please note the dialog below.  Why are you providing prototype in the dialog when it is an inactive control? Taunting perhaps?

Given my clients setup, I don;t know if there is a solution to this quandary in current software.  I'll post here if I find it.

So, here are the only solutions available which I have found in the current version of software:

1. Store all the wastewater feature definitions inside the drainage library. This is not practical given the desires of my client since the burden of library maintenance is spread across different groups.
2. In my project, before creating any sanitary models, copy all the sanitary conduit feature definitions from library to the project DGN. Then fill in the prototype from those populated from the hydraulic seed.  Needless to say, this fills my heart with dread from a training perspective.

Suggested solution from Bentley:

• Eliminate this ridiculous check altogether.  There are whole segments of the civil/survey world which don't give a tinker's dam about hydraulics. All they do is map and model underground utilities, including drainage facilities. Burdening these SUE practitioners with prototypes is unnecessary since they ONLY care about the physical. It should be user's burden and choice to configure prototypes or not.

Dog gone! This hole keeps getting deeper.  There is yet another gear in play for this problem.  A contributing aspect is the use of variable SUDA_Use_Haestad_Conduit = 1.   Because of this variable, then both drainage and sanitary feature definitions are looking for a Haestad conduit library and hence a prototype.   So, the check for prototype is less arbitrary than it appears.  But there are a LOT of moving parts here which make life very difficult when the hydraulics engineers are different than the sanitary engineers.  

A third solution to my problem then is to have completely different workspaces between utilities and drainage.  This is probably not objectionable to my client but creates a hardship for all my client's consultants.

Which leads to a suggested better solution in the software.  Forget the variable SUDA_Use_Haestad_Conduit = 1. It is too heavy handed and is built upon a mountain of assumptions.  Instead, if a conduit has a prototype then use the Haestad conduit library, if it does not then use the feature definition conduit table. Simple and explicit and eliminates assumptions.  Coupled with this, then prototype[es must be able to be read from a library rather than only from the active DGN.

Dog gone! This hole keeps getting deeper.  There is yet another gear in play for this problem.  A contributing aspect is the use of variable SUDA_Use_Haestad_Conduit = 1.   Because of this variable, then both drainage and sanitary feature definitions are looking for a Haestad conduit library and hence a prototype.   So, the check for prototype is less arbitrary than it appears.  But there are a LOT of moving parts here which make life very difficult when the hydraulics engineers are different than the sanitary engineers.  

A third solution to my problem then is to have completely different workspaces between utilities and drainage.  This is probably not objectionable to my client but creates a hardship for all my client's consultants.

Which leads to a suggested better solution in the software.  Forget the variable SUDA_Use_Haestad_Conduit = 1. It is too heavy handed and is built upon a mountain of assumptions.  Instead, if a conduit has a prototype then use the Haestad conduit library, if it does not then use the feature definition conduit table. Simple and explicit and eliminates assumptions.  Coupled with this, then prototype[es must be able to be read from a library rather than only from the active DGN.