How to "Visualize" an IfcWorkPlan in Bonsai?
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.
Comments
Hi @Rick_Brice , you need to add a
work scheduleto Bonsai, as you can see your model doesn't have itwork 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
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?
@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
@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.
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:
... and the first-sentence definition of IfcWorkSchedule is:
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.
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
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.
If I understand you the IfcWorkPlan is defined through the
IfcRelAggregatesrelationship, (meaning that it can aggregate multiple work schedules), while the IfcWorkSchedule controls a set of tasks and resources defined throughIfcRelAssignsToControl.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.
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
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":
If you change it to a valid date:
... then it works:
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?
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.
@Owura_qu
I tried to merge the two diagrams (from IfcWorkPlan and IfcWorkSchedule) into one, any thoughts?
in grey potential multiple schedules, plans, tasks
thanks
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:).
@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:
... or ...
... but not both together.
@Owura_qu
from previous posts I think it much depends on the level of detail and purpose of the tasks:
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!
@Moult
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
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)
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).
@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
@Moult
last one :)
in the above IfcWorkPlan image, can IfcWorkSchedule on the left have its own IfcTask?
cheers
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.
@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.
Indeed! My mind defaulted to the Component/ Standard/ Loadable Families (.rfa) :).
Thanks all. This is an interesting and informative discussion. For the problem I’m trying to solve, does it make sense to represent an assumed construction sequence as a root level IfcTask? From IfcWorkPlan
Task times are optional, so that eliminates the issue with uncertainty at design time. Also, the assumed construction sequence is basically milestones and not individual fine-grained steps. IfcTask can be a zero duration milestone.
As I dig deeper into this, it seems that Ifc4.3 falls a bit short for US bridge requirements. Consider a road corridor realignment project. The new alignment will cross a river and a highway with two different types of bridges. Within the project is one alignment and five sites. One site for each bridge and sites before, between, and after the bridges. Each bridge, being different types, will have different assumed construction sequences. If root-level task, work plan, work schedule are rel-declared with IfcProject, how are the construction sequences related to the proper bridge? None of Rel Assigns, Associates, or Connects subtypes seem appropriate.
-- EDIT --
I've answered my own question. IfcWorkPlan can be IfcRelDeclared to IfcProject is there is only one bridge. IfcWorkPlan can be IfcRelAssignsToControl if there is more than one bridge. Additionally, if more than one of the bridges are the same type, the same IfcWorkPlan (RelatingControl) can be assigned to several bridges (RelatedObjects).
@Rick_Brice typically the physical model will be associated to the IfcTask, not the IfcWorkSchedule. You'd use IfcRelAssignsToProduct as per the ICOM diagram (as an output) documented on this page: https://ifc43-docs.standards.buildingsmart.org/IFC/RELEASE/IFC4x3/HTML/lexical/IfcProcess.htm - so you'd assign it to the summary task.
If I understand you @Moult , my assumed construction sequence would be something like IfcTask(summary task, construct bridge) - RelNests - [ IfcTask(build piers), IfcTask(erect beams), IfcTask(cast deck) ]. Then IfcTask(construct bridge) - IfcRelAssignsToProduct - IfcBridge.
No need for IfcWorkPlan or IfcWorkSchedule?
No need for IfcProject-RelDeclares-IfcTask(construct bridge)?
This is what I'd recommend:
IfcProject <- RelDeclares -> IfcWorkPlan <- ... -> IfcWorkSchedule <- ... -> IfcTask (summary, construct bridge) <- Nest -> multiple IfcTasks as you describe, but you also need to relate them together with IfcRelSequence likely with FINISH_START relationships.
Here's a breakdown of why these relationships exist:
This matches exactly (apart from optional time information) the example provided by buildingSMART on how to show construction sequences.
This is completely supported in Bonsai, and also supported in Synchro and Bexel I believe.
Makes sense. I’ll give it a try. Thanks for your help and patience
I followed your recommendation and it seems to work well.
I went the extra step of IfcRelAssignsToProduct for the subtasks and the elements of the bridge. That is, I related the step 3 subtask to the deck and the step 4 subtask to the barriers, and so on.