Coating simulation code
                                       
                                   CONTENTS
                                       
     [1]Introduction
     [2]Programmer interface
     [3]What's a good problem?
     [4]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

References

   1. file://localhost/afs/cs.cmu.edu/project/learn/group/doc/coating.html#0
   2. file://localhost/afs/cs.cmu.edu/project/learn/group/doc/coating.html#1
   3. file://localhost/afs/cs.cmu.edu/project/learn/group/doc/coating.html#2
   4. file://localhost/afs/cs.cmu.edu/project/learn/group/doc/coating.html#3