I have come to the conclusion that despite there being a phasing attribute in AECOSIM there is no scope to leverage this in the application other than as an output.
In the event that we have modelled an existing building it appears the only way to manage the removed and retained elements is to put them in sperate files. Does anyone else have a better way to do this?
Ironically I have tried using named groups to knock out existing to demolish but the space flood tool sees the walls that are in the existing to demolish named group, see image (the green area is a space flood). Annoying really... I know its been said before, but named groups would be great if they were properly integrated with AECOSIM.
I had understood that space floods were going to be improved to flood only on the plane identified, is there a timescale for this to happen - I thought it was meant to have been doen for AECOSIM.
Unknown said:Ironically I have tried using named groups to knock out existing to demolish
How are you doing this? Sounds interesting...
Simply put within the existing model you have element in an existing to be retained group and an existing to be demolished group. When you attach the file as a reference it is possible to attach a named group within a file. Sounds great until you realise that AECOSIM ignores the namedgroups.
R
Thematic mapping is nice, but what happens when you need to export the info to dwg or even dgn for those vanilla Mstn users?
At some point, we need to be able to get DV/BV to re-symbolise to different levels ala DEM.....
Mine was not intended as a long-term solution, merely a current workaround until the ability to scale and resymbolize with more specificity is put into the product.
Thanks,
Shawn
------------
Unknown said: John, I would recommend creating a Part for Beams to be demolished that get assigned to a different Level than New beams. This could be assigned by a Catalog Item for Beams called Beams-Demolition (or whatever you want to call it). Then you could create a structural rule that is applied to the Steel::Beam-Demolition Part that either doesn't display it or displays it with a different symbology than new beams. -Travis
John,
I would recommend creating a Part for Beams to be demolished that get assigned to a different Level than New beams. This could be assigned by a Catalog Item for Beams called Beams-Demolition (or whatever you want to call it). Then you could create a structural rule that is applied to the Steel::Beam-Demolition Part that either doesn't display it or displays it with a different symbology than new beams.
-Travis
Travis
will the rule take that element away from the cut (so things behind it will be visible in front view.)?
regards / Thomas Voghera
I think its also important to make the differentiation between management in design and in drawings.
I'm back in three file world. Existing to Remain, Existing to Demolish and Proposed. Its the only way to sensibly manage things in AECOSIM sadly.
I hope someone at the farm is listening for the next go at things, because most of what has been discussed here is work arounds.
I'm also surprised that there doesn't seem to be any acknowledgement from Bentley that it would be a good idea to leverage the attributes in the application. There needs to be a shift away from thinking of AECOSIM as a glorified drafting application.
If you apply a "No Display" Rule to the existing members, I believe it should then process items 'hidden' beyond the existing member.
Unknown said: If you apply a "No Display" Rule to the existing members, I believe it should then process items 'hidden' beyond the existing member.
Are you saying that it is possible to create a 'rule' in a BV that tells all elements with phasing set to "existing to demolish" NOT to participate in the cut AND be displayed dashed and blue in cut and not displayed at all in front and rear?
Unknown said:Are you saying that it is possible to create a 'rule' in a BV that tells all elements with phasing set to "existing to demolish" NOT to participate in the cut AND be displayed dashed and blue in cut and not displayed at all in front and rear?
Not for architectural elements. For Structural elements you can apply a rule to a specific Part(s) for demolition (but not by elements with phasing set to "existing to demolish") that controls the symbology and/or display. For Mechanical elements you could use the criteria option "Results of Saved Query" to find all mechanical components with the phasing property set to "existing to demolish" and apply a rule to display ON/OFF and control the symbology.
In structural we have also used the Status field in the member information, but this has been more at a model level rather than in any drawings. Don't see why this field couldn't have it's use extended in AECOsim.
What are the chances of getting some common AECOsim fileds?
Yes, it would be good to be able to apply the Structural and Mechanical Rules to elements authored by the other 'disciplines'.
Structural rules can move elements to other levels. I think archie users were reliant on DEM for this.
Mech rules can target the graphics type by edge, centreline, insulation, lining and symbol. This could be a way to provide some basic LOD, if there was an 'suppress display' option.... so that you omit the insulation for example.
Would be good to be able to target hatches/fills, materials and set Display Priority as well.
There seems to a lot of rules that deal with re-symbolising to single/double lines. We should be able to deal with shapes as well. What if we need to show a fill for column sections or beams or slabs in plan?
Further down the line:
It will be good to have some assignment options to link particular Drawing Rules to particular Ref attachments? At the moment, it is primarily based on discipline via DGS or/and F+P, but also criteia or selection sets. What happens if you have a bunch of i-models from different parties, or a combo of i-models and live Ref models?
Should the Drawing Rule engine look at the SV to identify which Models to apply which DR set?
I imagine that you could get a bunch of models in from say Prostructures, and you wouldn't want to recreate a F+P definition from scratch. You would want to filter by IFC or CIS/2 attributes using Criteria Sets for those models when they are referenced, and apply your F+P set to your elements.
Being 'foreign' the Prostructures stuff should be re-symbolised 'once' and the results kept to avoid unnecessary reprocessing. Maybe the only bits that will need unfication with live models will need to be re-symbolised on viewing?
Criteria Sets are interesting. Should the Drawing Rule engine be able to 'mine' elements to differentiate... say... whether an edge is a longitudinal or end edge of a beam? Does it abut something? Or if the edge is part of an internal penetration / reveal? There are drawing conventions that require these edges to be drawn or re-symbolised differently. See Speedikon Viewfilters.
Bear,
Unknown said:What are the chances of getting some common AECOsim fileds?
Currently there are several definition files that are attached to all Catalogs (ObjectPhasing.xsd, ObjectClassification.xsd, maybe others) that in turn serve as a common AECOsim field. Is this the type of common AECOsim field that you are thinking?