Now set up the model's activation. swarmContext indicates where
we're being started in - typically, this model is run as a
subswarm of an observer swarm.
The ComputationalAssemblerBasic class instances make
computational processes; we have a computationa assembler instance for
each unit
THIS CLASS IS NOT USED DIRECTLY, BUT VIA THE INHERITING CLASS
ComputationalAssembler.java
computational operations with code -1001
this computational code places the numbers
of the recipes to launch from other recipes, via the c step 1002,
in position 0,0 of the received matrixes and set the status to done.
computational operations with code -1100 (a code for the jES Open Foundation
extension)
this computational step acts as generalized matrix loader that places the values
found in unitData0/memoryMatrixContents.txt file in the matrixex and rows and cols
reported in the same file
the number of the matrixes used here must be less or equal to totalMemoryMatrixNumber
(the first m matrixes of these ones); beside this, m has to be less than 10
it is mandatory to enter all the defined matrixes
in their original in the c 1100 m m1 m2 ... command
values in the unitData0/memoryMatrixContents.txt can be in any order
finally it changes the status to done;
computational operations with code -1101 (a code for the jES Open Foundation
extension)
this computational code creates a new random unit in the model stratum
reported in position 0,1 of the unique received matrix, with the probability
set in position 0,0 of the same matrix; finally it changes the
status to done
it returns the new unit address, to be used, if necessary, in
ComputationalAssembler.java
computational operations with code -1102 (a code for the jES Open Foundation
extension)
this computational code drops the unit the order is in, with the probability
set in position 0,0 of the first received matrix and increases the
position 0,1 of the second received matrix by 1, to count the dropped
units; this computational step must be in the last step of the order, because
the dropped unit cannot send it to the successive one; the computational step,
before setting the unit to be dropped, applies the orderDoneStep() method to
the order, for accounting purposes; finally it changes the status to done
computational operations with code -1103 (a code for the jES Open Foundation
extension)
this computational code creates a copy of the unit the order is in the model
stratum of the original unit, near to it with the standard placement rule, with
the probability set in position 0,0 of the unique received matrix;
the count of the created units is reported increasing by one the position
0+rd,1+cd of the second received matrix
finally it changes the status to done
computational operations with code -1110 (a code for the jES Open Foundation
extension)
this computational code creates a copy of the unit the order is in, in the same x,y place
of the copied unit, but in another model stratum, with the probability set in position 0,0
of the unique received matrix; the created unit is set in the stratum indicated in position
0,1 of the unique received matrix; the unit is created, with the above probability, if the
content of the unit memory matrix in position 0,0 is positive (the actual position can be
modified via the calling step, i.e. 1210 in tutorial step3c); if the destination position
in the new stratum is occupied the new unit is not created, without any advice; the
new unit is not created if the original one is in the destination stratum; the new unit
has the same visibility of the old one;
finally, the computational step changes the status to done;
c1110 is not normally utilized directly but via a special computational step (i.e. 1210
in tutorial step3c) setting the position and content of the cell (<=0 or >0) indicated above;
the memory matrix of the copied unit is shared among the original unit itself and its copies,
avoiding the creation of new matrixes for the copies
computational operations with code -1120 (a code for the jES Open Foundation
extension)
this computational code modifies the position 0,0 both of the memory matrix
of the unit the order is in and of the memory matrix of the unit the order
come from; the amount of the two modifications is defined by two addenda stored
in position 0,0 and 0,1 of the unique received matrix (the actual position can
be modified via the calling computational step, of the class 12xx); also the
position of the two memory matrixes can be modified via the via the 12xx calling
computational step; in 0,0 the addendum 1 for the unit the order is in and
addendum 2 for the unit the order come from; finally it changes the status
to done;
computational operations with code -1199 (a code for the jES Open Foundation
extension)
this highly usable computational code, when received by one unit in a stratum,
acts vs. all the units of the same type (i.e., with the same production
phase) in all strata; actions: with the probability
set in position 0,0 of the first received matrix, c1999 adds the value contained
in 0,5 of the second received matrix to each unit memory matrix a row and column
reported in pos 0,3 and 0,4 of the second matrix; if the resulting content is < the
level contained in position 0,2 of the second matrix, the considered unit is
dropped (if it is the unit the order is in, also the order is dropped), counting
the dropped units in position 0,1 of the second matrix (obviously, first and second
matrixes can be coincident)
finally it changes the status to done
computational operations with code -1999 (a code for the checking
phase of the program
this computational code verifies position 0,0 of the three
received matrixes; only if these positions are all not empty
the code empties them and set the status to done
a flag to avoid the control of the number of matrixes
this flag has to be used from a computational step using an existing step
and modifying on the fly the memory matrix number of the used computational
step
production done step in Order (it is in the orderRecipe vector,
at the index value in which we find the first 0 in orderState
vector minus 1; if no step has been done, the method returns -999999)
getting the computational specification set related to the nextStep
(the current one, if the order is in a waiting list for next step
to be accomplished)
if no computational specification set exists for the next step,
a null value is returned
the min level of inter-visibility; below this level two units cannot
exchange products; this value is not used in assignment coming from
OrderGenerator; this value can be different from one model to another: that
of the sending unit is used
the number identifying the memory matrix (starting from zero)
this number represents also the posizione of this memory matrix in an
array of memory matrixes created and managed by ESFrameModelSwarm
ActionGroup for holding an ordered sequence of action
(the numbers of the model action names are the same used in the full
jES model, so some are lacking in this version)
ActionGroup for holding an ordered sequence of action
(the numbers of the model action names are the same used in the full
jES model, so some are lacking in this version)
ActionGroup for holding an ordered sequence of action
(the numbers of the model action names are the same used in the full
jES model, so some are lacking in this version)
ActionGroup for holding an ordered sequence of action
(the numbers of the model action names are the same used in the full
jES model, so some are lacking in this version)
This method is used to collect the names of the units and of the end units, so that it can operate the check of
corrispondency between the production phases required by recipes and the phases of production the units can do.
setting (initializing) the number of ticks that the order is
in the dailyProductionList of a Unit; the setting is made in unitStep2; the
initial value is set in unitStep1
shuffle the lists at each assignment in the AssigningTool (this is done beside
the ordinary shuffle operations in each model schedule); the choice is related
to the units belonging to this stratum
the integer vector containing the unit of time spent for each step
in the recipe; il will determine the tranformation of the orderRecipe1
vector into the orderRecipe2 vector containing the repetitions
of the steps, to reproduce the length of each step in time
NB this formalism is internal to internal (in external formalism
we have 'step s/h/d time'
as an examples
orderRecipe1 contains 1 12 7 3
stepLengthInOrder contains 1 3 2 2
orderRecipe2 contains 1 12 12 12 7 7 3 3
the unit the order come from (null at the beginning, coming from distiller or
generator) NB must be a different unit, i.e. we do not register here the assignnment
to the same unit or to a unit executing the same step
The Unit class instances are micro unit in our virtual enterprise;
i.e. the units where the steps required to build a product (to fulfill
an order) are done
manage the lists in each cycle to have a unique assignment in each cycle to
each unit in the AssigningTool; the choice is related to the units belonging to
this stratum
at the beginning of each time tick in the 'day', each unit looks for
the order(s) (if any) to be executed; the production
cycle is 'one unit of time'
in a step of the recipe of an order in a tick of a day;