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?

Parents
  • Unknown said:

    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=" ?

    The SWA is just a scale factor. 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.

    Unknown said:

    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?

    Changing the SWA of a model after smart solids have been created can be problematic. The difference in scale between the old and new SWA will be applied when doing things like a Boolean union between solids and could easily make the solid too small or too large for the new SWA. So it all depends on the element size and new SWA scale whether it will cause problems to change it.

    Coincident world references will align your model's global origins...true scale will account for unit differences between the models. The SWA doesn't come into play until you copy elements between models or try to perform solids operations between elements in the master file and reference. To minimize potential problems for things like merging references, it's best to use the same unit setup for all models in a project.

    HTH

    NOTE: Changing resolution does not change the SWA scale as it's a uor scale (which means a 1 km SWA isn't the same number of uors when you have different unit settings for your models)...changing resolution after the fact is also not recommended, true scale/coincident world attachments are the way to go.



  • Hi Brien,

    Thanks very much for the response:

    1. So, if the project footprint should be as close to 0,0,0, ours, then we should be using GO=0,0,0¦ours?

    2. In some of one of the posts, you mentioned smartsolids were not initially updated to have a 'floating' SWA origin. Can you confirm whether AecoSIm's Forms have been updated?

    3. I also seem to recall that there was a recommendation to remain within the 4.29m cube at a high resolution for DEM to work properly. Is this still the case? In which case, we have a problem with our current settings.

    4."Coincident world references will align your model's global origins...true scale will account for unit differences between the models."

    But if everyone is modeling at 0,0,0¦ours, then Train Station A can't Ref Train Station B with CW/True Scale.... right?

    What the heck happens when you activate a Ref...?

    5. "Changing the SWA of a model after smart solids have been created can be problematic. The difference in scale between the old and new SWA will be applied when doing things like a Boolean union between solids and could easily make the solid too small or too large for the new SWA. So it all depends on the element size and new SWA scale whether it will cause problems to change it."

    Surely, there should be a tool to recalibrate the solids to maintain their 'real world' dimensions when the user changes the SWA scaling? A 10m beam should stay 10m. The recalibrating tool would rejig whatever Parasolids looks at to maintain mathematical happiness?

    6. Will 64bits help? You don't see this kind of fiddling required of the poor user with most apps....?  Even CAD Admins have trouble getting their heads around this stuff.

  • Dom,

    Frm experience, AECOsim does not use a floating SWA. We've gone back to renaming the GO, for AECOsim projects.



  • Unknown said:

    1. So, if the project footprint should be as close to 0,0,0, ours, then we should be using GO=0,0,0¦ours?

    You can set the global origin to whatever you like so that 0,0,0 uors reflects the real-world coordinate of that location.

    Unknown said:

    2. In some of one of the posts, you mentioned smartsolids were not initially updated to have a 'floating' SWA origin. Can you confirm whether AecoSIm's Forms have been updated?

    Yes, the code was modified to treat the SWA as floating in some early version of V8. There was never anything stored on the elements that would make them fixed or floating, it's just how the code chooses to interpret the SWA.

    Unknown said:

    3. I also seem to recall that there was a recommendation to remain within the 4.29m cube at a high resolution for DEM to work properly. Is this still the case? In which case, we have a problem with our current settings.

    I don't know anything about the DEM and it's limitations.

    Unknown said:

    4."Coincident world references will align your model's global origins...true scale will account for unit differences between the models."

    But if everyone is modeling at 0,0,0¦ours, then Train Station A can't Ref Train Station B with CW/True Scale.... right?

    What the heck happens when you activate a Ref...?

    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.

    What happens with what when you activate a reference?

    Activating a reference just lets you work in the local coordinates of that attachment in the context of a particular view. It's not any different than exchanging into that model in that regard.

    Unknown said:

    5. Surely, there should be a tool to recalibrate the solids to maintain their 'real world' dimensions when the user changes the SWA scaling? A 10m beam should stay 10m. The recalibrating tool would rejig whatever Parasolids looks at to maintain mathematical happiness?

    The solid doesn't change size in Microstation, it only changes size with regards to the solids kernel. Unlike a feature solid (and I assume AecoSIm forms) a smart solid can't re-play the feature operations in order to compute a new brep for the new SWA, a smart solid stores the brep data at the size/precision of the SWA at the time it was created. If you've created a 1 mm smart solid with a 100 km SWA, changing the SWA to 1 km won't magically increase it's precision...

    Unknown said:

    6. Will 64bits help? You don't see this kind of fiddling required of the poor user with most apps....?  Even CAD Admins have trouble getting their heads around this stuff.

    No...it's not a memory issue. A solids modeling kernel needs to work at fixed sizes to ensure the necessary precision, i.e. how far apart 2 points need to be to be considered distinct, etc.

    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.

    HTH

    -B



Reply
  • Unknown said:

    1. So, if the project footprint should be as close to 0,0,0, ours, then we should be using GO=0,0,0¦ours?

    You can set the global origin to whatever you like so that 0,0,0 uors reflects the real-world coordinate of that location.

    Unknown said:

    2. In some of one of the posts, you mentioned smartsolids were not initially updated to have a 'floating' SWA origin. Can you confirm whether AecoSIm's Forms have been updated?

    Yes, the code was modified to treat the SWA as floating in some early version of V8. There was never anything stored on the elements that would make them fixed or floating, it's just how the code chooses to interpret the SWA.

    Unknown said:

    3. I also seem to recall that there was a recommendation to remain within the 4.29m cube at a high resolution for DEM to work properly. Is this still the case? In which case, we have a problem with our current settings.

    I don't know anything about the DEM and it's limitations.

    Unknown said:

    4."Coincident world references will align your model's global origins...true scale will account for unit differences between the models."

    But if everyone is modeling at 0,0,0¦ours, then Train Station A can't Ref Train Station B with CW/True Scale.... right?

    What the heck happens when you activate a Ref...?

    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.

    What happens with what when you activate a reference?

    Activating a reference just lets you work in the local coordinates of that attachment in the context of a particular view. It's not any different than exchanging into that model in that regard.

    Unknown said:

    5. Surely, there should be a tool to recalibrate the solids to maintain their 'real world' dimensions when the user changes the SWA scaling? A 10m beam should stay 10m. The recalibrating tool would rejig whatever Parasolids looks at to maintain mathematical happiness?

    The solid doesn't change size in Microstation, it only changes size with regards to the solids kernel. Unlike a feature solid (and I assume AecoSIm forms) a smart solid can't re-play the feature operations in order to compute a new brep for the new SWA, a smart solid stores the brep data at the size/precision of the SWA at the time it was created. If you've created a 1 mm smart solid with a 100 km SWA, changing the SWA to 1 km won't magically increase it's precision...

    Unknown said:

    6. Will 64bits help? You don't see this kind of fiddling required of the poor user with most apps....?  Even CAD Admins have trouble getting their heads around this stuff.

    No...it's not a memory issue. A solids modeling kernel needs to work at fixed sizes to ensure the necessary precision, i.e. how far apart 2 points need to be to be considered distinct, etc.

    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.

    HTH

    -B



Children
  • 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.