Coating simulation code

CONTENTS
Introduction
Programmer interface
What's a good problem?
Playing with the code

Introduction

The Coating simulation problem is a scheduling problem described elsewhere. The code for the problem can be found in g/coating/*.c For the simplest programmers interfce to it, use the functions defined below.

Programmer interface

A probspec is a specification of a coating problem. To create a probspec, call

      probspec *mk_probspec_from_file(char *fname);

An example of a suitable file is g/coating/test.prob. This gives the number of objects of each coating type (represented by a letter) required.

Example:

      a 10900320
      b  5126400
      c  0
      d  6189120
      e 40222000
      f  0
      g 0
      h 0
      i 0
      j 0
      k 0
      l 0
      m  0
      dead1_days 19
      dead2_days 24
      max_scrap_frac 0.1

dead1_days is the fixed time of running the process: there is no benefit in finishing sooner than this time.

dead2_days is the maximum amount of time for running the process. During this time, overtime costs accrue at $500 per hour.

max_scrap_frac reduces the number of configurations to consider, by only permitting ones whose fraction of scrapped products is less than this.

      void free_probspec(probspec *ps);
      void fprintf_probspec(FILE *s,char *m1,probspec *x,char *m2);

The user may directly inspect the following fields of a probspec:

        int num_coat_codes;

The number of different coats being manufactured on this month. In the above example it is 4.

        char *coat_codes;

A string whose i'th character is the i'th coat code. In our example, it is "abde".

        dyv *coat_requires;

The i'th element of this vector is the number of objects needed with the 'th coat_code. In our example

                            (  1.09003e+07  )
      ps -> coat_requires = (   5.1264e+06  )
                            (  6.18912e+06  )
                            (   4.0222e+07  )

        double dead1_days;

Explained above

        double dead2_days;

Explained above

      int probspec_num_configs(probspec *ps);

Number of legal configs to consider.

The following is the next state function for our system:

      double production_profit(probspec *ps,dyv *start_need,double start_mins,
                               int config_number,
      			 dyv **r_end_need,double *r_end_mins,bool *r_stop);

The vector "need" and the double "mins" (mins since start of month) constitute the state of this system. The state state has needs = coat_requires and mins = 0.

The action is the choice of config_number, which must be 0 <= config_number < int probspec_num_configs(probspec *ps);

The production_profit function chooses automatically how long the config is run for. The resulting need is vector is DYNAMICALLY ALLOCATED and returned via *r_end_need. The resulting mins (how long the line has now been run) is returned in *r_end_mins.

If time has run out (i.e. we're at the end of overtime) or we've made everything we needed to make *r_stop will be true, else *r_stop will be false.

The function returns the profit (-ve denotes loss) for this choice of state-action pair.

What's a good problem?

test.prob may be too easy. regular.prob is the standard monthly requirement, but it is allowed to use two lines (the send line runs at about 60% of the line simulated here) so is probably much too hard.

Playing with the code

run coating/api. There is a wait for the table of configuration outcomes to load. See the code that calls the above API functions in the last function in api.c