CE: New Approach for Text Substitution

Interesting!

I think that you are using Item Types embedded in the title blocks to look up an Excel table.

So, the corresponding fields in the title block would not be editable in the Sheet model?

What would be great is if you can have bi-directional updates. A change in the title block / Sheet model would update the Excel table as well.

Also, is there a way to jump to the Excel table from the title block / Sheet model ? Engineering Link?

I agree it would be nice if it was bi-directional for updates. But I find that it is not too much of an inconvenience to open the Excel file for updates. It is very useful to have a single Excel source that can be modified to reflect text field changes in 100 files.

I don't believe there is a way to "jump to the Excel table" from the text field links in the sheet model.

Karl Todt said:

It is very useful to have a single Excel source

I agree!  Bi-directional data exchange sounds good, but raises the question "Which is my primary data source?"

That is not to say that transmitting data from MicroStation to Excel is a bad idea.  In fact, it's a good idea that Bentley Systems have implemented in their Report tool.  You can already query Item instances in a Report and export that Report to external data sinks, such as Excel.

Jon Summers said:

You can already query Item instances in a Report and export that Report to external data sinks, such as Excel.

Yea.. I wonder if the next step would be to embed / store the Excel table in a dgn and bypass Excel altogether. :-)

Jon Summers said:

raises the question "Which is my primary data source?"

Yes, I suppose one benefit of having bi-directional updates is that there would be a mechanism to avoid / answer this question. If all the manifestations of the data is always synchronized, then every thing is 'primary' or 'single source of truth'...

But, the devil is in the detail. For example, say you roll your own and provide a means of looking up an external table and do not provide the means to lock the calling object (the title block in this case); and/or provide a reasonably idiot-proof means to jump to the primary data source, then you can bet that you will have consistency and other problems later on... easily negating any initial productivity gains.

CE has started to provide tools to support 'model based documentation'... which is good, but what is still a bit missing is a Revit-style 'Parametric Change Engine'.

Dominic Seah said:

Yyou can bet that you will have consistency and other problems later on

Yes: a hole in one!  Those problems bedevilled older GIS tools (MicroStation GeoGraphics) that stored non-graphic data in an external database.  That's one reason why Bentley Map moved to XML-based Feature Modeling (XFM) as the DGN internal data store.  I guess that XFM informed EC Schemas and subsequently Item Types.  EC Schemas define that single source of data. 

I think that Bentley Systems should make more noise about EC Schemas.  They have a splendid technology embedded in their base platform, MicroStation.  It's the essence of a coherent BIM story.

Dominic Seah said:

Yyou can bet that you will have consistency and other problems later on

Yes: a hole in one!  Those problems bedevilled older GIS tools (MicroStation GeoGraphics) that stored non-graphic data in an external database.  That's one reason why Bentley Map moved to XML-based Feature Modeling (XFM) as the DGN internal data store.  I guess that XFM informed EC Schemas and subsequently Item Types.  EC Schemas define that single source of data. 

I think that Bentley Systems should make more noise about EC Schemas.  They have a splendid technology embedded in their base platform, MicroStation.  It's the essence of a coherent BIM story.

Jon Summers said:

They have a splendid technology embedded in their base platform, MicroStation.  It's the essence of a coherent BIM story.

Agreed. EC Schemas, SQLite based imodel formats and the new i.modelHub stuff I think are signs that Bentley have got the storage side of things down. But, at the moment, it is all based on pessimistic transaction management which requires manual intervention when updating/propagating changes.

This is OK for some workflows, just like using an external database or spreadsheet is fine when the data flows are mainly one-off or read only like the way manufacturer's electrical product data is normally stored as a .mdb or  spreadsheet(s).

But not great when there are frequent and bi-directional updates. As I understand it. the prevaling update management approach is tool-centric so if you write some code or an addin, then you are responsible for telling the system how and what to update to maintain consistency. The problem is you are one of many tools all stepping on each others toes and occasionally overloading the system.

Time to provide something like PCE... and provide some kind of 'traffic cop' API so that all components are written with 'parametric change at the center from the ground up'?

This sheet numbering workflow is a good example of why storage only tools like Item Types are often not sufficient on they own. The sheet numbers that are stored in the spreadsheet or dgn will not only need to be inserted into the Sheet model title block. They will also need to be inserted into the callouts in drawings that refer to the sheets. So when you change a sheet number you will need to find all parties referencing that number. This is where all that bi-directional complexity comes in and causes problems. Where is the 'primary'? Who cares... as long as it is consistent, right?

And what if that info has a callback registered against it by another tool? That could have another subscriber and so on.

Again, it falls to the tool maker... I think Mstn's Sheet Indexing and Dynamic Views creation tools take centre stage... and has still not suceeded in providing a robust solution after years. No PCE API? Constant let's try a new pattern churn? Too many scenarios to error trap? Or too difficult, let's wait for HQ to sort this one?

dominic SEAH said:

The sheet numbers ... will also need to be inserted into the callouts in drawings that refer to the sheets. So when you change a sheet number you will need to find all parties referencing that number

A text field can store a reference to an Item instance property.  If that property changes, then MicroStation's dependency manager is triggered and the text field is updated.  Multiple text fields can reference the same property, so the dependency manager should update them all.  Or, do you mean something different?

dominic SEAH said:

Time to provide something like PCE

If only we knew what PCE means.

[Edit] It turns out that it's Revit's Parametric Change Engine.

Jon Summers said:

If that property changes, then MicroStation's dependency manager is triggered and the text field is updated. 

The Dependency Manager does not work across Ref files, AFAIK. When setting up drawings, it is standard practice to generate separate 'composition' files to reference the 3d models and generate the DV; which then is referenced in a Drawing model; which is then referenced again in the Sheet model. Standard stuff given Bentley's federated 'divide and conquer' approach.

But when the callback is fired, the subscribing party needs to be loaded and almost always isn't. So, the tool maker will have to roll his own method of managing the deferred updates some how.

As you know, there is also the bigger and badder Relationship Manager

Jon Summers said:

he MicroStationAPI document tells us that the Relationship Manager is a 21^st century replacement for the Dependency Manager.  I have existing dependencies (i.e. using the Dependency Manager) and am investigating whether to move to the Relationship

which sounds like will do a lot of the things that Revit's Parametric Change Engine (PCE).

Paul Chater said:

Its very rare that an application would need the sophistication and complexity associated with the RelationshipManager. The animator in Microstation is the only subsystem which requires it, for all the other subsystems the DependencyManager API's are more than sufficient.

The Relationship system allows you to construct a Directed Acyclic Graph of relationships which can be topologically sorted into an execution order. A simple example with the animator is  an actor (A) moves along a path, the path is then in another actor (B) which is also moving and the camera (C) needs to target actor (A) and the camera (C) is also moving via parametric motion. The with the RelationshipManager you can setup and solve the execution order of relationships in this type of system.

If there are situations where you think that the existing DependencyManager is insufficient I would suggest you ask for help with it before using the RelationshipManager as using will involve considerable investment of time and understanding of its API's.

.. probably still doesn't handle cross file dependencies, but at least it does try to create a Directed Acyclic Graph (DAG) and in doing so should be streamling and managing the torrent of callbacks, checking for circular dependencies, exceptions... marshalling callbacks, managing rollbacks etc etc ??

Looking at the Revit PCE patent:

"a method for propagating changes through a plurality of elements in a design model may comprise analyzing changes in a first element, generating a step to carry out at least some of the changes, generating a first plurality of steps based on a predefined relationship between the first element and one or more other elements, or upon changes in a predefined relationship between the first element and one or more other elements, and executing the steps to reflect changes in the model. The method may also generate a second plurality of steps that are based on the first plurality of steps and relationships among the plurality of elements. The method may also sort the steps to ensure that a step is not executed before one of the steps on which it depends. The method, in particular embodiments, may generate steps through prediction or through guessing. The method may also verify that the steps were carried out in the proper order."

"A runtime class may represent wildcard dependencies, which are dependencies on all of the elements 16 of a particular type, rather than on a single element 16. A runtime class may be represented as metadata, and may also be displayed. For example, an element 16 having a runtime class may keep track of all the rooms in model 14, and may deduce where a particular room is located by examining walls and lines in model 14. Such an element 16 would depend, among other things, on the centerlines of each of the walls that defines every room, and the atom representing the dependency would not need to have a particular element ID. In such a manner, the area of rooms in model 14 can be tracked automatically even as changes are made to model 14."

"Several components of system 10 propagate changes that are made to elements 16 in model 14 when the model is regenerated. In general, function 32 may be performed on an element or elements 16, and through rules 36, may impose certain actions or functions on other elements. Each time an element 16 is changed in the course of modifying model 14, the atom or atoms 24 that correspond to the changed data are “touched.” Each time atom 24 is touched, some sort of alteration or multiple alterations will need to be made to model 14 when model 14 is regenerated. The alterations are carried out by one or more steps 34 when regeneration of the model occurs. System 10 may provide a step repository 44 to organize the touched atoms 24 and the steps 34 that are created to alter the atoms 24. Step repository 44 may store indicators for the changed atoms 24, it may store steps 34 that are computed as atoms 24 are changed, or it may store both. Additional steps 34 may be created during regeneration and stored in step repository 44. Step 34 may make changes to an element or serve as a placeholder to indicate that a change has already been made to an element.

... you wonder if whether the old Dependency Manager is really fit for purpose for today's BIM workflows.

You are the author of Flexitable, which is a 'mini' Excel that sits within Mstn. How would you synch information across Ref attachments? This example by AB_DATE manages table data stored in separate models (one for each floor) in the same dgn. What if the models were stored in separate files? How would you go about managing and ensuring consistency? 

And, the data -being in table format- will be useful, so... some other punter will want to do a look up the stuff stored in your tables.... and won't be able to fire up your code to ensure everything will be managed and integrity preserved. Yes, some one-directional stuff might still be OK, but bi-directinal updates will be required somewhere to ensure the / everyone's 'primary source' is consistent.

End result: little 'islands of automation' in that lake of dark data that just get in the way later and is not fit for purpose in todays BIM world.