Skip to Main Content
iTwin Analytical Services Ideas Portal

If IE does not provide a description field, try alternative browser

Status Needs review
Created by Guest
Created on Aug 4, 2023

iTwin updates should only change the analytical data, nothing else!

the symbology of our framing plans is driven by a pretty extensive list of rules. we apply those rules by part and family assignments (if this p/f then use this rule). we work predominantly with RAMSS. it does not allow for accurate modeling of TOS in some cases (a dropped terrace area on an upper floor). We adjust for that in ODB by applying offsets to the members, usually a minus y number to drop the steel down. We do not move the member. that would mess with the analytical line for the element. we simply use an offset.

after our first import, we go through and change the part/family as needed as well as apply offsets, if needed. we create our plans.

the problem comes when we do the subsequent update from iTwin. even if those few members we modify did not move (end points do not change) or change design (size, cambers, studs, reactions), iTwin resets the part/family to the default and resets the offsets back to 0.

this is really frustrating. we can't be reworking p/f assignments and offsets after every import. annoying for a small model. an incredible waste of time for a large one, bordering on impossible to remember all the incremental tweaks we've made during design.

when an element gets updated in OBD, the only things that should get updated are the analytical components - section size, analytical end points, camber, studs, reactions, grade of steel, etc. iTwin should care less if I apply offsets. if the end points move, absolutely move the end points. but we need the offsets to compensate for analytical and modeling differences. do NOT set theme back to 0.

similarly, if the element already exists, iTwin should care less about the assigned part/family. leave it alone and just modify the analytical changes. if the element does not exist, give it the default part/family, but don't reset it back to the default every time.

if you don't understand what I'm frustrated with here, shoot me an email and we can arrange a phone call to discuss.

  • Attach files
  • Vytautas Valiukonis
    Reply
    |
    Aug 27, 2024

    Ok, I think I realized where the limitation lies. There is no way of specifying (tagging) some elements which you don't want to change. This makes the Workflows feature limited and this workflow a good suggestion.

  • Guest
    Reply
    |
    Aug 23, 2024

    maybe I can revisit this. Seth told me about this some time ago, but it wasn't helping at the time.
    for example, if I have a beam on a terrace, you can't 'drop' it in RAM (the only application we use for our steel design). so, once it comes into AECOsim we use a y or z offset to drop it down. problem is, next time we update from the iTwin, that y/z offset gets reset back to 0. I don't recall there being something in the workflow that says 'don't change the offsets'. but, it's been a while.
    also, we were using part/family to drive our symbolization on the plans - if 'this' part/family, use 'that' rule. every time we update from the iTwin, all of our part/family changes in AECOsim get reset back to the default. it seemed like the workflow rules were allowing you to pick and choice what to update, which might be good, but everything else it was getting set back to the default values. not helpful at all.

  • Vytautas Valiukonis
    Reply
    |
    Aug 22, 2024

    It seems like the "Workflows" feature might be very useful in this case.

    When exporting/importing your model make sure to select the "Show Change Management" checkbox. By default, "Workflows" menu pops-up at start, if it doesn't go to "Settings → Workflows".

    In "Workflows" menu you will be able to craft specific rules to your use case (these rules can be saved, so they only need to be created once). For example you might set it to only accept design (size, cambers, studs, reactions) and automatically reject everything else.

    If you think that this use case cannot be solved this way we would be happy to discuss it over a call.