OSArch Community

How to "Visualize" an IfcWorkPlan in Bonsai?

  1. R

    The AASHTO Bridge Design Specification (Article 2.5.3) requires that contract documents contain the assumed construction sequence for a bridge. I've been trying to accomplish this in my IFC model. See discussion at https://github.com/jwouellette/TPF-5_372-Unit_Test_Suite/discussions/16

    My question to all the Bonsai experts - is how can I see a representation of the work plan and all of its tasks and subtasks in Bonsai? Or maybe export it to something else?

    Ping @steverugi because you are an expert with 4D and bridges.

    Attached is my model with the IfcWorkPlan.

  2. S

    @Rick_Brice said:

    The AASHTO Bridge Design Specification (Article 2.5.3) requires that contract documents contain the assumed construction sequence for a bridge. I've been trying to accomplish this in my IFC model. See discussion at https://github.com/jwouellette/TPF-5_372-Unit_Test_Suite/discussions/16

    My question to all the Bonsai experts - is how can I see a representation of the work plan and all of its tasks and subtasks in Bonsai? Or maybe export it to something else?

    Ping @steverugi because you are an expert with 4D and bridges.

    Attached is my model with the IfcWorkPlan.

    Hi @Rick_Brice , you need to add a work schedule to Bonsai, as you can see your model doesn't have it

    work schedules can be contained in a work plan

    do you have a sequence of tasks with duration to share? Visualization of a work schedule (Gantt chart) it's pretty straightforward in Bonsai, through browser

    Tomorrow I can share a quick clip on how to do it, I'd like some little time to go through the very interesting discussion you shared too

    cheers

    credit to @SigmaDimensions, the real expert when it comes to 4D in Bonsai, I believe he's the author of that particular feature and recent updates ;)

    EDIT

    I am not sure Bonsai can add/edit an IfcTask to an IfcWorkPlan as indicated in the page

    I had a quick look at your sequence in the GitHub page, what is the problem of having an abstract sequence as IfcWorkSchedule? would it be sufficient?

    EDIT2

    I don't think you can add/edit Psets to an IfcWorkPlan as you propose in the GitHub, only to IfcWorkSchedule, at the first glance using an abstract sequence seems a more straightforward way of doing it in Bonsai

    awaiting your input

  3. R

    Thanks @steverugi . There is no work schedule because I'm trying to represent the construction sequence assumed during design. It is just a sequence of tasks and sub-tasks without dates or durations.

    I'm experimenting with different ways to satisfy the following requirements. The only thing required in the contract documents (which I'm interpreting as the model) is the sequence.

    Bonsai may not have the capability. That's ok... Any other ideas on how to demonstrate the model contains the required construction sequence?

  4. S

    @Rick_Brice

    I added more lines at the end of my previous post, did you read it?

    I think the sequence can be done using IfcWorkSchedule using IfcTask with no dates or duration (but with nested tasks and sequence)

    tomorrow I can try something

  5. R

    @steverugi - I did not see your edits. I'll review.

    IfcWorkSchedule may do the trick with Bonsai, but I don't think it's the right entity.

    An IfcWorkSchedule represents a task schedule of a work plan, which in turn can contain a set of schedules for different purposes.

    An IfcWorkPlan represents work plans in a construction or a facilities management project.

    I need to represent an assumed construction plan (sequence). That seems to better fit the definition of IfcWorkPlan.

     

    The goal is to use the right IFC type, even if Bonsai doesn't support it yet. There needs to be a standard and consistent method of satisfying the information requirements.

  6. M

    Bonsai currently only has the ability to add tasks to IfcWorkSchedule, not IfcWorkPlan.

    However this is an ambiguous part of the IFC schema. The first-sentence definition of IfcWorkPlan is:

    A work plan contains a set of work schedules for different purposes (including construction and facilities management)...

    ... and the first-sentence definition of IfcWorkSchedule is:

    An IfcWorkSchedule represents a task schedule of a work plan ...

    So taken at face value, it seems the "primary logic" is that IfcWorkPlan contains IfcWorkSchedule, and IfcWorkSchedule contains IfcTask. Whether IfcTask has dates or not is not mentioned at all in the spec - so it is irrelevant whether or not the IfcTask has dates, is planned, actual, or a baseline.

    This hierarchy is also used in example files received from other vendors, which has influenced our interpretation of it. See the official docs example.

    However, the docs also has two diagrams showing an IfcWorkPlan directly containing an IfcTask, and an IfcWorkSchedule directly containing an IfcTask.

    The difference between whether an IfcTask belongs to an IfcWorkSchedule or an IfcWorkPlan is unclear: it is not defined in the specification. You might have an interpretation of it (which may be correct) but at the moment it is not something the specification gives a clear answer to. There is no further explanation other than that single diagram and no examples by vendors or offical sources.

    If I follow your logic, you seem to propose that the reason IfcWorkPlan is more appropriate in this scenario is because it is merely a process sequence, not a "schedule with times". I cannot find this logic in the specification. In fact, I see evidence of the opposite, since the specification describes facility maintenance tasks which include things like punch lists which are also sequences of tasks (with no dates or time) which explicitly are mentioned to be part of IfcWorkSchedule.

    Given that, until we get a clearer answer of "how is IfcWorkPlan designed to be used in IFC?", I'd say just go ahead and use IfcWorkPlan -> IfcWorkSchedule -> IfcTask. All vendors have this same implementation.

  7. R

    I’m not really proposing anything. I just want to understand and do it right. Ambiguous specs don’t help with that. If work plan - work schedule- tasks is the common interpretation, I’ll give it a try.

    I don’t see small issues like this being discussed in our BIM for Bridges or Infrastructure research projects so I wanted to dig in a bit to see if I could find an acceptable method of satisfying the information requirements imposed on the bridge designer by the AASHTO specifications

  8. R

    I took Dion's advice and tried to generate IfcWorkPlan->IfcWorkSchedule->IfcTask. Model attached.

    Not much changed in the Bonsai UI. The only difference I see is the chevron to the left of Work Schedules now points downwards, but I don't see the tasks assigned to the work schedule.

    Any suggestions?

    From my bridge software, I'm trying to generate a IFC model and view it in Bonsai.

  9. O

    @Moult said:>

    However, the docs also has two diagrams showing an IfcWorkPlan directly containing an IfcTask, and an IfcWorkSchedule directly containing an IfcTask.

    If I understand you the IfcWorkPlan is defined through the IfcRelAggregates relationship, (meaning that it can aggregate multiple work schedules), while the IfcWorkSchedule controls a set of tasks and resources defined through IfcRelAssignsToControl.

    From the docs, since the IfcWorkSchedule also references a project via the IfcRelDeclares (including schedule time information such as start time, finish time, and total float) can we assume that as a clear answer to "how is IfcWorkPlan designed to be used in IFC?".

    I can imagine that a task can be performed under an IfcWorkPlan as well as under an IfcWorkSchedule and therefore an IfcTask can belong to both. Just my humble thoughts.

  10. S

    @Rick_Brice said:

    I took Dion's advice and tried to generate IfcWorkPlan->IfcWorkSchedule->IfcTask. Model attached.

    Not much changed in the Bonsai UI. The only difference I see is the chevron to the left of Work Schedules now points downwards, but I don't see the tasks assigned to the work schedule.

    From my bridge software, I'm trying to generate a IFC model and view it in Bonsai.

    it looks like your software created a WorkPlan, Work Schedule and IfcTasks but Bonsai cannot read them, but are there

    it needs to be investigated a bit how relations (don't) work in your file compared to Bonsai's

  11. M

    Your file is invalid, which led to an error so the interface couldn't render your work schedule. IfcWorkSchedule requires an IfcDateTime data type for CreationDate and StartTime but you have "Unknown":

    
    #102=IFCWORKSCHEDULE('0lv6If8orBchIG0WkLVUga',$,'Assumed Construction Sequence',$,$,$,'Unknown',$,'Satisfies the requirements of AASHTO LRFD BDS 2.5.3',$,$,'Unknown',$,.PLANNED.);
    

    If you change it to a valid date:

    
    #102=IFCWORKSCHEDULE('0lv6If8orBchIG0WkLVUga',$,'Assumed Construction Sequence',$,$,$,'2020-01-01',$,'Satisfies the requirements of AASHTO LRFD BDS 2.5.3',$,$,'2020-01-01',$,.PLANNED.);
    

    ... then it works:

  12. R

    Thanks, and sorry to waste your time with such a silly mistake. As I go through this exercise I wonder if work schedule is the right approach to represent an assumed construction sequence.

    IfcProcedure looks promising. The example is construction of a hamburger sandwich.

    What do you think about IfcProject-IfcRelDeclares-IfcWorkPlan-IfcRelAssignsToControl-IfcTask-IfcRelNests-IfcProcedure to represent the assumed construction sequence?

  13. M

    From what I read on IfcProcedure (that hamburger example is really, really silly) the specification seems to hint at its usage in terms of BMCS processes and emergency processes. Things like "After 9pm, if motion is detected, alarm is raised", and "If fire detected, then shut dampers".

    In other words, whilst it's not illegal to use IfcProcedure (and IfcEvent, they go hand in hand), my gut feel after coming through this portion of the IFC specification is that this is not the intention. IfcTask still seems more appropriate. That said, your interpretation on this is as good is anyone elses :)

    There is currently no support in Bonsai for this. In general, we only build support for things when the specification is clear.

  14. S

    @Owura_qu

    However, the docs also has two diagrams showing an IfcWorkPlan directly containing an IfcTask, and an IfcWorkSchedule directly containing an IfcTask.

    If I understand you the IfcWorkPlan is defined through the IfcRelAggregates relationship, (meaning that it can aggregate multiple work schedules), while the IfcWorkSchedule controls a set of tasks and resources defined through IfcRelAssignsToControl.

    From the docs, since the IfcWorkSchedule also references a project via the IfcRelDeclares (including schedule time information such as start time, finish time, and total float) can we assume that as a clear answer to "how is IfcWorkPlan designed to be used in IFC?".

    I can imagine that a task can be performed under an IfcWorkPlan as well as under an IfcWorkSchedule and therefore an IfcTask can belong to both. Just my humble thoughts.

    I tried to merge the two diagrams (from IfcWorkPlan and IfcWorkSchedule) into one, any thoughts?

    in grey potential multiple schedules, plans, tasks

    thanks

  15. O

    @steverugi said:

    I tried to merge the two diagrams (from IfcWorkPlan and IfcWorkSchedule) into one, any thoughts?

    The diagram is clear in illustrating the relationships but I believe the problem of “which one do I use” (IfcWorkPlan or IfcWorkSchedule under certain circumstances) may still be a complex (semantic) decision. I don’t know your take on that though since this area is much of your expertise:).

  16. M

    @steverugi yeah, that's one interpretation. Another interpretation (which I believe is correct) is that the project relationship is only required if it is not already referenced indirectly. For example:

    • IfcProject -> IfcWorkPlan -> IfcWorkSchedule -> IfcTask

    ... or ...

    • IfcProject -> IfcWorkPlan -> IfcTask

    • IfcProject -> IfcWorkSchedule -> IfcTask

    ... but not both together.

  17. S

    @Owura_qu

    from previous posts I think it much depends on the level of detail and purpose of the tasks:

    • for a simple sequence where there is no time component (start, finish, duration, calendar..) maybe IfcWorkPlan with relevant tasks could be the way to go, to indicate abstract activities and their sequence (start-end or similar) with some nesting. Not implemented in Bonsai.

    • whereas time is a necessary component IfcWorkSchedule is needed, implemented.

    As I posted earlier I don't see why IfcWorkSchedule (maybe with a PredefinedType = workplan ) cannot be used as abstract with no time information, after all it can potentially contain the needed data, but I might miss something important here.

    To be honest I always thought IfcWorkPlan in IFC was a sort of parent container for IfcWorkSchedule , just learned that it can also have tasks, always good to learn something!

  18. S

    @Moult

    @steverugi yeah, that's one interpretation. Another interpretation (which I believe is correct) is that the project relationship is only required if it is not already referenced indirectly. For example:

    1. IfcProject -> IfcWorkPlan -> IfcWorkSchedule -> IfcTask

    2. IfcProject -> IfcWorkPlan -> IfcTask

    3. IfcProject -> IfcWorkSchedule -> IfcTask

    This means that when IfcTask is directly controlled by an IfcWorkPlan no IfcWorkSchedule (and its IfcTask) should be in the same IfcProject and the three cases above are mutually exclusive? Just for me to clearly undestand it.

    Many thanks

  19. S

    it seems to be in contrast with this image, where an IfcWorkSchedule is there (OK it doesn't show its own IfcTask but what is it there for otherwise? genuine question)

  20. M

    To be strict, both IfcWorkPlan and IfcWorkSchedule inherit from IfcWorkControl, and IfcWorkControl has mandatory CreationDate and StartTime attributes, so it's impossible for either of them to have absolutely zero time information.

    In terms of EXPRESS definition, IfcWorkPlan and IfcWorkSchedule are identical. They only differ in the (ambiguous) written documentation, diagrams, and example files.

    @steverugi sorry, let me rephrase my previous post, as a general rule if something X (such as IfcTask) is already contained in something else Y (such as IfcWorkSchedule), where Y is directly or indirectly Declared to the project, then something X must not also have its own project declaration.

    The project rule in IFC is basically so that the IFC graph has an "entry" point. From the IfcProject, everything else can be navigated to through relationships. It is then unnecessary to relate something twice to the project.

    So it does not contradict that image (which I actually helped create, I transcribed it from the IFC4 docs which actually lost some information in the process).

  21. S

    @Moult

    thanks a lot for the explanation (and patience), always appreciated

    It would be nice one day to have it translated in some visual for people like me who struggle with certain semantics (my bad)

    cheers

  22. S

    @Moult

    last one :)

    So it does not contradict that image (which I actually helped create, I transcribed it from the IFC4 docs which actually lost some information in the process).

    in the above IfcWorkPlan image, can IfcWorkSchedule on the left have its own IfcTask?

    cheers

  23. O

    @Moult said:

    The project rule in IFC is basically so that the IFC graph has an "entry" point. From the IfcProject, everything else can be navigated to through relationships. It is then unnecessary to relate something twice to the project.

    I believe this explains why in Bonsai, unlike some other BIM software (e.g., Revit), you can create a window or door directly inside the project without the need for a wall to host it.

  24. M

    @steverugi yes, it can.

    One diagram which has heavily influenced my conclusion of a IfcWorkPlan primarily being used to group a series of related IfcWorkSchedules is this diagram here on IfcConstructionResource: https://ifc43-docs.standards.buildingsmart.org/IFC/RELEASE/IFC4x3/HTML/lexical/IfcConstructionResource.htm - as you can see the idea is that you'd copy / paste your work schedule multiple times and compare them using baselines. The IfcWorkPlan then offers a logical way to "group" iterations of the schedule.

    @Owura_qu in Revit you can also create a window or door without needing a wall, using model-in-place.

  25. O

    @Owura_qu in Revit you can also create a window or door without needing a wall, using model-in-place.

    Indeed! My mind defaulted to the Component/ Standard/ Loadable Families (.rfa) :).

  1. Page 1
  2. 2

Login or Register to reply.