Project SWA + Resolution Questions

Marc has added some interesting material on his blog on AecoSim settings.

We are working on a project with the following settings:

Resolution: 10000 per Meter

Solids Working Area: 429.496 Kilometers

0,0,0 is about 81 km away from the centre of the project.

Both seem to be well above the recomendations suggested in Marc's blog above:

Resolution: 10000 per MM

SWA 4.29km

Q1: Is the SWA is centred on the Design Cube? If so should we be moving the DC centre closer to the project footprint? Is this done by using "GO=" ?

Q2: Should we be changing the resolution/SWA mid stream? What happens if we need to reference some 'infrastructure-scale' models? Will referencing using Coincident World take care of this?

  • Unknown said:
    What problems are you actually having...and what fiddling are you required to do? So far it seems like you are inferring problems from various sources, not all of which are accurate.

    Fair comment about inference: the problem I am having is primarily do with miserable DEM performance (item 5). We have a project that has a immediate foot print of 400 x200m. We have DEM cuts that fail more often than succeed, and even when they do finish there are all kinds of problems with them. We have resorted to making extractions in 26 No.'tiles' across the site, and have to spend a huge amount of time embellishing / correcting the results.

     

     

    Unknown said:
    Train station A and train station B will have different global origins that re-define 0,0,0 uors so that they can be reference at their real-world location.

     

    Hmmm.... sounds like the precision of all that math is based on the origin defined by the GO= command, not the origin defined by the ours...?

    If so, then am I right in thinking that the resolution of the dgn should be set to provide a working area that is large enough to encompass both train stations? Using the recommended AecoSim resolution of 1000 units per mm, gives the user a working plane of 9,007,119 km to populate his train stations with, each with a floating SWA of 4.29 km to model within.

    So, if the point that xy=0,0,0 gives you is more than 4.29 km away from the project footprint (80+ km in my case), then we should be looking at moving it using GO=...?

     

     

  • Unknown said:

    Hmmm.... sounds like the precision of all that math is based on the origin defined by the GO= command, not the origin defined by the ours...?

    No.

     



  • Dominic,

    If your elements are already a large distance from the absolute center of the design cube that could very well be causing the DEM issues you referred to - things like missing lines, overlapping lines, "zingers", etc.   The accuracy required to represent elements using a hidden line display at a specific view orientation (depending on your cut and F/R) is similar to 3D modeling.  So the less precision available to calculate those edges, the more chance for incorrect results.  

    To re-state one of Brien's previous notes: "Ideally you should model near 0,0,0 uors and use GO= to specify the real-world coordinate of 0,0,0...this will avoid potential problems with large floating point numbers."   I've seen cases in the past where moving the 3D elements back near the design cube center instantly resolved DEM output issues after recalculation.   It's impossible to say that this is the root cause for your case, but it seems like a reasonable explanation.