Introduce an attribute to IfcWorkSchedule that defines by which calendar is IfcRelSequence LagValue calculated

[JovanMarkovicBexel]

If the TimeLag attribute of the IfcRelSequence entity is set to be worktime (IfcTaskDurationEnum.WORKTIME) it's not clear by which calendar the task relation lag should be calculated.

In order to specify which calendar is used for task relation lag calculation, it's necessary to introduce a new enum attribute to the IfcWorkSchedule that has the following values: • PredecessorTaskCalendar • SuccessorTaskCalendar • ScheduleDefaultCalendar This way it would be absolutely clear which calendar should be used for task relation lag calculation.

[Moult]

This is a joint answer by @myoualid who also implemented this with me.

This is a valid problem. We investigated how this worked in Oracle P6 and we found that they seemed to take the worse case scenario of both calendars.

In our implementation, we followed this guidance:

• https://github.com/IfcOpenShell/IfcOpenShell/blob/v0.7.0/src/ifcopenshell-python/ifcopenshell/api/sequence/cascade_schedule.py#L57-L58
• https://github.com/IfcOpenShell/IfcOpenShell/blob/v0.7.0/src/ifcopenshell-python/ifcopenshell/api/sequence/cascade_schedule.py#L68-L69
• https://github.com/IfcOpenShell/IfcOpenShell/blob/v0.7.0/src/ifcopenshell-python/ifcopenshell/api/sequence/cascade_schedule.py#L79-L80
• https://github.com/IfcOpenShell/IfcOpenShell/blob/v0.7.0/src/ifcopenshell-python/ifcopenshell/api/sequence/cascade_schedule.py#L90-L91

The worst case of the two is considered:

https://github.com/IfcOpenShell/IfcOpenShell/blob/v0.7.0/src/ifcopenshell-python/ifcopenshell/api/sequence/cascade_schedule.py#L96-L97

Option 1:

Specify in the documentation that in this scenario, both calendars should be considered and the worse case (i.e. latest or maximum date) shall be used in date calculations.

Pro: matches existing behaviour of planning software in industry and so what people might expect Con: Extra work for developers to code it, could be surprising results for users

Option 2:

Option 2A: IFC should store an attribute at the work schedule level to specify which calendar is used for lag calculation when cascading dates / recalculating the entire schedule. Option 2B: IFC should store an attribute at each lag time attribute to specify which calendar is used.

Pro: user has fine grain control over exactly which calendar applies to the lag time, or user gets predictable behaviour on recalculating schedules Con: do users really care? Isn't it extra work (especially if used at each lag time attribute)? A user never really thinks about this and we only come across this because we're building it. Also exports from P6 and other software may come out differently in IFC

[Moult]

I was wrong.

I asked a domain expert and he says:

In P6 there is an option to select between 1 & 2 I prefer for the successor to drive the next activity. its an option for the over all program.

In that case I fully support Option 2A, which is exactly your original proposal :) Here's it a little fleshed out:

Name: DefaultLagTimeCalendar
Description: Which calendar drives date calculations when a lag time has a DurationType of WORKTIME.
Enum values:
 - PREDECESSOR: Lag time duration is defined in terms of the predecessor task's calendar
 - SUCCESSOR: Lag time duration is defined in terms of the successor task's calendar

I have excluded the third value because there is no 'default' calendar (at least now there isn't) and calendars can be inherited.

How does that sound?

[JovanMarkovicBexel]

Yes, option 2A sounds great. Some tools (e.g. P6) could be configured to use the Project Default Calendar for task relation lag calculation and that is the main reason why I suggested the third possibility.

I also want to point out that from my point of view, the most logical behavior is to use a successor task calendar for task relation lag calculation but in IFC all cases should be covered.

[Moult]

Some tools (e.g. P6) could be configured to use the Project Default Calendar for task relation lag calculation and that is the main reason why I suggested the third possibility.

This is a great opportunity to decide whether or not that is a good or bad thing. If it is a good thing, we should include it. If the domain experts believe this P6 feature is actually not a good thing, maybe we don't need to include it :)

I'm not a domain expert, so happy for you to make the judgement.

I would like other domain experts from the construction room to comment on this issue before we mark this as decided though, just 2 people (and I'm not a domain expert) does not sound enough for a rapid consensus. Ping @myoualid

[Moult]

Bump.