wssuite / nursescheduler Goto Github PK

These costs are hardcoded, which is not convenient for generality of our code.

If the output folder /outfile/parameter_file/instance_name/ is not created before running the solver, it is not created anywhere and the solution files are written nowhere, hence the impossibility to run the validator.
We should create the folder automatically when not present nor user-specified.

Try a stronger formulation of the rotation MP where each worked week-end leads to a new level until the maximum number of weekends is worked. At the last level, every rotation where a weekend day is worked is penalized.
This requires a major revision of the subproblem, since there is one day-shift node per level. Optimality can only be certified by solving one subproblem per level.

Currently, preferences on rest and work periods are specified on specific shifts. Actually, it seems reasonable that these requests could be on all shifts of a given type on a given day (just like they can be on all shifts of a given day).
Currently, this can be done by enumerating all the shifts of a given type in the preferences, but a more explicit specification would be preferable.

I will so sorry if I disturb you. I adore you very much. I hope to be your student fortunately ! ! !

The default parameters does not compute an optimal solution and, even worse, does not goes to optimality at the root node (so the root LB is wrong!).

It seems that the methods for fixing and relaxing days, shifts, etc. are all defined in the MasterProblem.cpp although they should be specific to the the decomposition. This will be of importance if the LNS is extended to the rotation decomposition.

Many integers are used through the code to represent objects or indices, but could lead to bugs. We need something more robust.

We know that cutting planes have allowed for major improvements of VRP solvers. There would be a need to scan the litterature for good cutting planes for workforce scheduling.

1- Have the notion of shift and shift type. Different shift can be performed during a certain shift type and each of them has also a demand
2- A shift has also a time consumption for a min/max constraint over the horizon: generalized the min/max worked days (consumption of 1 day).
3- The preferences are more general: the shift off request has 4 levels from weak to compulsory (very high cost). There is also a field shift on request now (could be used to fix part of the solution).
4- The subproblem has been modified to be able to be solved with/without the enumeration of all the short rotations.
5- A major refactoring has been done: the code is now separated into sub-directories. The subproblem has been recoded in an object oriented mind. The rotations have been removed from the pricer and Bcp to allow more general object into the code.

WARNING: there is a bug with the readerwriter, the preferences are not parsed correctly (the same line is always read)

Greedy is never used, but still appears in the code. For instance in DemandGenerator::checkDemandFeasibility, which by the way does not seem to be used either.

When the time limit does not allow for the computation of a feasible solution, the code runs into a segmentation fault. It should be caught.
For reproduction:
./bin/staticscheduler --dir datasets/ --instance n030w4 --weeks 6-2-9-1 --his 1 --param paramfiles/default.txt --sol outfiles/default/n030w4_1_6-2-9-1 --timeout 10

This part of the code has not been revised for a long time. Need to work on it to make it more clear.