From: Roland Hautz (insal047h_at_inn-salzach.de)
Date: Thu Mar 20 2003 - 18:13:45 CET
Date: Thu, 20 Mar 2003 18:13:45 +0100 (CET) From: Roland Hautz <insal047h@inn-salzach.de> Message-ID: <Pine.LNX.4.44.0303201521080.2133-100000@isabella.iivs.de> Subject: Re: [taskjuggler-devel] I'd like to contribute an optimizing scheduler
Hi,
On Thu, 20 Mar 2003, Chris Schlaeger wrote:
> > Exploitation of this algorithm would demand slight modifications of the
> > taskjuggler language. Also a mapping between calendar time and the
> > discrete time slots of the algorithm still needs to be written. Then it
> > could be used as alternative or complete replacement of Task::schedule().
>
> Can you describe the necessary changes a bit more detailed. You can also send
These notions used in the algorithm's description need to be mapped to
language constructs: activity, mode, duration, renewable resource,
available renewable resource units, nonrenewable resource, available
nonrenewable resource units, units of renewable resources used in modes in
each period, units of nonrenewable resouces consumed in modes.
'task' for activity is obvious.
Modes can be painlessly mapped to special sub-'task's. At least a new
boolean attribute 'task'->'mode' is needed for this. However I'd
suggest 'mode' as synonym for these sub-'task's.
Tasks containing modes must not contain certain other attributes.
Of the 3 or so (;-)) offered time attibutes of tasks, 'length' seems to be
fitted best for the duration of modes.
'resource' is obviously the renewable kind. I hope
'resource'->'efficiency' is a suitable unit. It would be silently
mapped to a properly scaled discrete value.
The intended semantic of 'task'->'allocate'->'load' is not quite clear to
me. If it means "units used from the resource in each planning
period", that would be fine. Else a new attribute is needed for this.
Something like this could already be used for available nonrenewable
resources and their units:
account NR1 "nr 1" revenue { credit $projectstartdate "budget" 13.0 }
I could imagine prettier solutions though.
The biggest problem is, that 'task'->'account' must allow multiple
values like 'task'->'allocate' does. For this to work properly,
'startcredit' and 'endcredit' should be changed to optional attributes
of 'task'->'account'.
In a mode
"account NR1 { startcredit 2.0 }"
could then denote consumption of a nonrenewable resource.
Surely I didn't think of everything yet and the list is to be continued.
> me the code if you like. Since TJ uses discrete time slots internally there
Code sent in a PM.
> is already a mapping function. See the scoreboard handling code in
> Resource.cpp.
Resource::scoreboards are probably a base. But a single calendar-slot map is
needed by the algorithm, not one for every resource. And for efficiency reasons
of the algorithm, every slot where no resource is available needs to
be filtered out.
And a last but not least problem: Via the scoreboards it seems that every resource
is limited to one task at a time. Resources should of course for
the optimizer be freely distributable among all requesting tasks.
In short I need Slots having Resources instead of Resources having Slots.
> I'm certainly interested. An optimizer has been on my TODO list for a while
> now. But since it is currently only needed when you use alternative
> (non-persistant) resources, most people can live with the current algorithm.
> I'd like to add support for a skill-based resource selection and then an good
> optimizer is really a must have.
Well. If nobody wants to use it for real problems, we could try to
position it as game AI. ;-)
-- Roland -- To unsubscribe, email: taskjuggler-devel-unsubscribe@suse.com For additional commands, email: taskjuggler-devel-help@suse.com
This archive was generated by hypermail 2.1.7 : Thu Mar 20 2003 - 20:36:40 CET