ORD Drawing Production - Nesting Depth Value 99

RE: ORD Drawing Production - Nesting Depth Value 99

Keith Kennon — Mon, 14 Aug 2023 12:10:56 GMT

Doesn't the associated Saved View take a snapshot of the references so that when changes are made downstream of the container, it is not inherited by the sheet models? Using the Saved View has its advantages and drawbacks, but avoiding drilling down 99 levels may be one of the advantages.

RE: ORD Drawing Production - Nesting Depth Value 99

Mark Plum — Sat, 12 Aug 2023 06:22:50 GMT

I checked into this issue today, and- after testing some load times both in PW and operating directly from a server partition, I could really see no difference. Such is odd because I respect the opinions of all of you who have contributed to this thread, and I thought I would truly see some differences. I had a similar discussion a few weeks ago with some folks who thought that working on a PW managed environment was much faster than working directly on a server with SSD's. I saw no difference there either. I believe that some other things are going on here.

Best Regards,

Mark

RE: ORD Drawing Production - Nesting Depth Value 99

Mark Shamoun — Sat, 12 Aug 2023 04:54:35 GMT

I may be misunderstanding the issue, but I don't see any undesired nesting coming into play in any of our drawing files. Although the drawing model has nesting of 99 it doesn't actually change downstream nesting levels of any of the references.

Regarding performance, we have found that the second you create a Civil model in your DGN, nesting level limits get ignored on first file open of a session. It will cycle through ALL references and ALL their references (and even the same references being loaded in different models). This is not specific to drawings, this is more apparent in them because of the additional references they have. It also is more prominent for models with Profile views and 3d cuts because you are adding more reference trees for it to load. It gets worse in ProjectWise because it then also loads different versions of the same file.

The reason it apparently does this is because it needs to load all models to ensure the dependencies and rules all stay intact. I have been debating that why can't it just load what it needs to? The reference manager warns you when you try to detach a file that there are dependencies so it should be able to be "detected". Also, I am of the opinion that ORD should only allow users to build rules to a maximum Nest Level of 1 and there needs to be a change to how rules are built to reference files IMO - why is every instance of a reference detected as a separate object? If this wasn't the case, we could "restore" relationships broken by accidental detachment and ORD would not repeatedly load the same DGNs on file open.

You can see we have been thinking a lot about this haha

RE: ORD Drawing Production - Nesting Depth Value 99

Flounder_Pounder — Fri, 11 Aug 2023 17:59:12 GMT

The fact that nesting depth doesn't appear to respect standard controls or limits is an issue, simply because, if we have developed our settings for a nested depth of 2, we aren't expecting a nesting depth of 99. The software shouldn't be overriding the other settings (see Tim's post on this thread).

Nesting that goes any deeper than our desired container model setup runs the risk of a nested attachment we didn't intend.

Not to mention the performance issues as mentioned above and below.

RE: ORD Drawing Production - Nesting Depth Value 99

MaryB — Fri, 11 Aug 2023 17:06:21 GMT

Nesting that goes any deeper than our desired container model setup runs the risk of a nested attachment we didn't intend.

Not to mention the performance issues as mentioned above and below.

RE: ORD Drawing Production - Nesting Depth Value 99

Robert Garrett — Fri, 11 Aug 2023 16:53:12 GMT

Yes, we have seen issues like you describe. It was worse in versions prior to 10.10 but can still be a source of slow file load. Projectwise has the potential to magnify the slow load times. For our clients, I always describe the potential for slow load times and for them to adjust the depth to 5 or less when/if it becomes a problem.

RE: ORD Drawing Production - Nesting Depth Value 99

Steve Tissier — Fri, 11 Aug 2023 16:04:22 GMT

I was under the impression that the 99 nesting depth was a primary cause of performance issues, especially on large projects working on ProjectWise. We are certainly experiencing that now on a large project, but i haven't done detailed testing to verify that is the issue.

RE: ORD Drawing Production - Nesting Depth Value 99

Mark Shamoun — Fri, 11 Aug 2023 10:24:50 GMT

Someone correct me if im wrong, but is this really an issue?

Although Nesting of the Sheet/Drawing models are set to 99, it will not override the nest level of the references downstream, ie. only dig down to the respective nest levels for each nested reference. The setting of 99 just caters for an instance you ever have nested references going that deep (which no one would), but ive never seen it go any deeper than the settings used in the design models.

The file open nested reference loading ssue is something a little different and is not affected by specific Nest levels in the DGN. They fixed it in Microstation CE 17.2, but my understanding Civil models still have this issue due to how it loads dependencies (which i hope gets fixed soon).

RE: ORD Drawing Production - Nesting Depth Value 99

Mark Plum — Fri, 11 Aug 2023 02:35:30 GMT

Steve:

I am on ORD 10.12, and my best recollection is that this issue is still the case. I will check again when I get into the office tomorrow.

Best Regards,

Mark

RE: ORD Drawing Production - Nesting Depth Value 99

Steve Tissier — Fri, 11 Aug 2023 02:30:45 GMT

Anyone know if this is still an issue? Crazy if it is.

RE: ORD Drawing Production - Nesting Depth Value 99

Flounder_Pounder — Fri, 12 May 2023 22:48:02 GMT

Any updates on this? Wondering why also, using 10.10 r2

RE: ORD Drawing Production - Nesting Depth Value 99

MaryB — Tue, 04 Jan 2022 21:15:17 GMT

Sounds like a bug to me...

RE: ORD Drawing Production - Nesting Depth Value 99

Tim Hickman — Tue, 04 Jan 2022 19:46:31 GMT

If I use the reference tools for attachment, the product follows the default configuration settings, but if I use the sheet creation (sections, etc...) , this process does not honor the default settings.

Not sure is this works as designed, or it is a bug.

Bentley will need to inform us as to how it is intended to work.

RE: ORD Drawing Production - Nesting Depth Value 99

Bruin Ramsdell — Tue, 04 Jan 2022 15:17:53 GMT

Nope, we have default nest depth=0, and still generating sheets with the Named Boundary drawing and sheet views are created with a nested depth of 99.

RE: ORD Drawing Production - Nesting Depth Value 99

Tim Hickman — Mon, 03 Jan 2022 18:29:19 GMT

you want to look at the MS_REF_DEFAULTSETTINGS variable.

I am assuming this is not currently set for you.

In your case you want it set to Depth=2

IE: MS_REF_DEFAULTSETTINGS = depth=2

also don't forget to enable live nesting as well (nestmode=live)

RE: ORD Drawing Production - Nesting Depth Value 99

MaryB — Mon, 03 Jan 2022 18:19:33 GMT

Yes. Default nesting of 99 files does indeed slow down file opening times.

Why would the DGNLIB file allow us to set a nesting level if that level is going to be ignored?

Do the programmers have ANY real-world experience USING the software? Do they KNOW anyone who uses the software? Do they consult with anyone who uses the software?

There is getting to be a critical disconnect with the way the software is being written, and the needs of real-world engineering production teams.

RE: ORD Drawing Production - Nesting Depth Value 99

Bruin Ramsdell — Mon, 03 Jan 2022 16:30:28 GMT

Bump, not that anyone is listening. 99 live nesting slows down file speeds, and takes forever to fix when you have 1000's of cross section drawing/sheet models to go through to fix it.

RE: ORD Drawing Production - Nesting Depth Value 99

Chris Snyder — Wed, 06 Oct 2021 22:38:13 GMT

Just confirmed this is still an issue in version 10.10. Then needs fixed ASAP to avoid having to post-process files.

RE: ORD Drawing Production - Nesting Depth Value 99

MaryB — Fri, 11 Dec 2020 16:41:14 GMT

Why do we need to amend it? Because most often we will only want a nesting depth of 1 or 2. We don't want every reference attached to everything everywhere.

RE: ORD Drawing Production - Nesting Depth Value 99

Matthew Ashby — Fri, 11 Dec 2020 11:43:11 GMT

Here is my understanding of nesting depth, which might be flawed. For discussion purposes, assume the following:

A - parent model (i.e., a model in a DGN file) - e.g., the sheet model in a cut sheet

B - a separate model or DGN file - e.g., the container file that has other base files referenced and attached to it

C - separate model or DGN file - e.g., a base file that contains the existing topography, or the existing utilities, etc.

D, E, F, G - separate models or DGN files - ancillary files

Next, consider that file C has models D thru G attached to it as "direct" references. What I mean by direct is that live nesting is turned off and is not being used in file C.

Next in file B we have attached file C and are using Live Nesting.

Next in file A we have attached file B and are using Live Nesting.

So the only way to see file C in file A is to have the value of live nesting set to 2 or higher. However, if we use a value of 3 or say 99, then MS will start to trickle down and "display" other base files that weren't intended to be attached. For example, in file A we now will likely be "seeing" files D thru G because they are attached directly to file C. This is behavior that I don't want, and to avoid this requires getting pretty specific for the value of the nesting depth.

RE: ORD Drawing Production - Nesting Depth Value 99

Mark Marnell — Fri, 11 Dec 2020 08:00:14 GMT

99 is the maximum value possible with nested levels. While I cannot talk for the developers, they may have set it so high just to ensure that the 'maximum case scenario' is covered. Your DGNLIB will not have all the survey, mapping, utility files etc referenced in, so the nesting level number will not match the 'real world' number.

Why do you need to amend it post-production? Does it affect the file opening times or something?