ISM as consolidated model?

In our office, often we find ourselves with multiple engineers working on each project.  One engineer may be responsible for the lateral systems, one may be responsible for concrete joists, and a third may be responsible for steel (penthouse, mechanical levels etc).  Further we may have an engineer responsible for coordinating slab edges with architects. With so many people in a model, making daily changes (and backups) things quickly become fragmented.

This leads to a fundamental problem with RAM Structural System that I'm wondering if ISM is capable of mitigating.   My thought is that at the outset of a project, a RAM model is built, then pushed to and ISM repository.  Then, each engineer could maintain their own RAM model split from the original, using update to/from  ISM to stay up to date.  Is this a functional workflow?  Are there potential pitfalls associated with this idea?

If I'm reading this link correctly, then Rebar for concrete elements could be written to the ISM repository, but not read back into RAM models? Is this feature on the development map in the near future?

I'm looking forward to any words of wisdom and/or experience with this idea.

Parents
  • Unknown said:
    My thought is that at the outset of a project, a RAM model is built, then pushed to and ISM repository.  Then, each engineer could maintain their own RAM model split from the original, using update to/from  ISM to stay up to date.

    One would hope that this is possible... Seth?

    What about nodes / loads that would need to transfer across the model's file based boundaries? Does ISM track GUID's or whatever indexing system that RAM uses?

    Say the engineers have some model for the superstructure and another for the basement. The superstructure columns would be sitting on the basement columns and slabs. Would one be able to link and propagate changes to the other?

Reply
  • Unknown said:
    My thought is that at the outset of a project, a RAM model is built, then pushed to and ISM repository.  Then, each engineer could maintain their own RAM model split from the original, using update to/from  ISM to stay up to date.

    One would hope that this is possible... Seth?

    What about nodes / loads that would need to transfer across the model's file based boundaries? Does ISM track GUID's or whatever indexing system that RAM uses?

    Say the engineers have some model for the superstructure and another for the basement. The superstructure columns would be sitting on the basement columns and slabs. Would one be able to link and propagate changes to the other?

Children
  • Not much has changed in this regard since the original post.  The idea is sound and I ran through a few simple model tests and it could work. The workflow would be something like this,

    1. Initial Model A is created and designed
    2. Original ISM repository is created
    3. Use save-as to create a replica of the first model, Model B
    4. Make changes to Model A and Model B
    5. Use update Repository from either Model A or B to update the ISM repository
    6. Use Update from Repository when you want to propagate those changes across the models.

    However, there are some concerns. Foremost, you want to be careful accepting any part deletions. For example, If Model A has foundations designed, but Model B is for refining the framing, the foundations might not be designed in Model B, so if you update the repository form model B you want to be careful not to delete the foundations. Or more generally, for a user/model that is for some specific purpose, be careful to only update those aspects of the repository for which that user is responsible.

    You can update the ISM gravity loads (surface loads), but I am not able to pass those changes from one RAM SS model to another via ISM (i.e. loads export but not import). Furthermore, lateral loads are only saved in the Ram Frame data (not in ISM). 



  • Great news!

    Unknown said:
    so if you update the repository form model B you want to be careful not to delete the foundations. Or more generally, for a user/model that is for some specific purpose, be careful to only update those aspects of the repository for which that user is responsible.

     

    This should be easy to implement as a ruleset. Each element in the ISM would know its origin, and it should be relatively straight forward to lock those elements in RAM? Mstn / Aecosim already can lock elements. Not sure if RAM has as well.

    Unknown said:
    You can update the ISM gravity loads (surface loads), but I am not able to pass those changes from one RAM SS model to another via ISM (i.e. loads export but not import). 

    Sounds like a missing implementation. Is there a list of missing stuff like this?

    Unknown said:
    Furthermore, lateral loads are only saved in the Ram Frame data (not in ISM) 

    It would be good to be able to save this info in the ISM. It sounds like the info transfered and tracked by ISM very much use-case based. In this case, the expectation is that the ISM is geared to just transfering selected info to a detailing or layout app like Prostructures? Not between say RAM and STAAD? But, even then I can see having the load info being useful in PS.

    Last year's Year in Infrastructure has a presentation by WSP on 22 Bishops Gate, which is a high rise project in London, using RAM as one of its apps. On such a large structural frame, it would be clear that there would be more than one structural engineer and RAM models having to collaborate closely. Things like load transfers should NOT be transfered or re-created manually, and a central repository like ISM would be very useful.

    Mstn has been very successful in no small part due to its ability to break up files usings Ref attachments. It would be good to have the same 'DNA' in the analytical apps as well.

  • Great feedback. The gravity load limitation is one of a few things in ISM, but not fully supported in RAM SS. For a more complete list see: communities.bentley.com/.../5379.capabilities-and-limitations
    Lateral loads are a tricky bit. In RAM SS, the force associated with a wind or seismic load is generated during analysis based on a set of criteria. Ideally it's the load defining criteria we would want to save, but in ISM, loads are just forces associated with a node or member.