Jump to content
Simio Forum

gdrake

Members
  • Content Count

    85
  • Joined

  • Last visited

Community Reputation

0 Neutral

About gdrake

  • Rank
    Senior Application Engineer
  • Birthday February 10

Converted

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. gdrake

    Time varying appointment arrivals

    Add a 'NumberArrivals' data column to the data table that is defining the arrival schedule. For example, define your arrival schedule table like this: SomeArrivalTableName ArrivalTime NumberArrivals 8:00 am 5 8:30 am 5 9:00 am 10 9:30 am 8 etc. Then on the Source object, specify the Arrival Mode as 'Arrival Table'. Specify the Arrival Time Property as 'SomeArrivalTableName.ArrivalTime'. Specify the Arrival Events Per Time Slot as 'SomeArrivalTableName.NumberArrivals'. Note that you can also easily add columns in the data table as well for the Arrival Time Deviation and No-Show Probabilities, and then map those columns to the corresponding properties in the Source. For example, if the Arrival No-Show Probability actually differs depending on the day of week or period in the day.
  2. gdrake

    Routing Logic Vehicle Initial Home

    You can dynamically assign the 'HomeNode' state variable of a vehicle or worker object (e.g., ASSIGN: Vehicle1[1].HomeNode = BasicNode1 or ASSIGN: Vehicle.HomeNode = BasicNode1 if the vehicle of interest is associated with the token executing the Assign step). The 'Initial Node (Home)' property is simply the initial value assigned to that node reference state variable of the vehicle or worker. I'll have the property description of that 'Initial Node' property updated to make sure to note the state variable that can be dynamically assigned to change the home node location.
  3. 1) Add a state variable to you model that is the switch control variable. For example, add an integer state variable named 'MySwitchControlVar'. 2) Specify the variable that you created as the Switch Control Variable on the Flow Node. 3) On each of the possible outbound links that can be chosen, in the Selection Weight expression for the link enter an expression like 'MySwitchControlVar==1' which would say for that particular outbound link, send flow to that link if the switch control variable has a value of '1'. 4) Add your own state assignment logic to assign that switch control variable a new value whenever you want to 'switch over' to sending flow to a different outbound link from the flow node. There may be a SimBit (a small example) installed with Simio that illustrates the approach. The description text of the Switch Control Variable property also provides some of the same information that I provided above.
  4. A possible rough approach: 1) Add a data table. Let's name it 'Node_In_KeyTable' table. This table has a single column named 'Node_In' of type Node property (to take a node name). Set that column to be a Key column. 2) Add another data table. Let's name it 'Node_Out_ProbabilityTable'. This table has three columns. It has a FOREIGN Key column named 'Node_In'. Specify the Table Key of that foreign key column to be 'Node_In_KeyTable.Node_In'. Then add a 'Node_Out' node property column and a 'Probability' numeric column to that table. 3) So...above, you have set up two tables with primary-foreign key relationships. 4) In some model logic, you want to assign an entity a destination from the 'Node_Out_ProbabilityTable', First, use a SetRow step to assign the entity a row in the 'Node_In_KeyTable' that corresponds to the 'Node_In' that you are interested in. Because there is a primary-foreign key relationship between that table and the probability table, that is going to automatically filter down the selected row set to just be the referenced rows. 5) You could then do something like this: SetNode step whereby the Node Name is specified as Node_Out_ProbabilityTable[Node_Out_ProbabilityTable.Probability.RandomRow].Node_Out. Looking at that expression, what you are doing is you are going into that table, you are indexing into that table looking at the probability column by picking a random row using probabilities (which will only be the selection set corresponding to the 'Node_Out' key)...and pulling out a 'Node_Out' node reference.
  5. Mark, just an FYI that in Sprint 102, the following objects in the Flow Libary: Tank ItemToFlowConverter FlowToItemConverter Have all been enhanced to provide new 'Purge Contents Triggers' functionality. For the Tank object, the 'Purge Contents Triggers' feature will allow you to specify conditional event-driven triggers that will immediately remove and dispose of any contents held in the tank, putting the tank into an empty state. This will easily allow you for example to clear residual flow contents in a tank due to round-off errors, by having the tank perform a conditional check when some specified event occurs (e.g., each time a filled container exits a Filler that the Tank is supplying, then purge the tank if the remaining contents is smaller than some epsilon quantity). A 'Purge Contents' trigger might also be defined to purge/flush/clear the Tank for any other sort of reasons, to reset the flow line back to an empty state. For the ItemToFlowConverter object, the 'Purge Contents Triggers' feature will allow you to specify conditional event-driven triggers that will immediately remove and dispose of any generated flow waiting to exit the converter object, putting the converter's flow container into an empty state and cancelling any further outflow for the discrete item entity whose conversion was in-process. For the FlowToItemConverter object, the 'Purge Contents Triggers' feature will allow you to specify conditional event-driven triggers that will immediately remove and dispose of any inflow collected by the converter object for creating the next discrete item entity, putting the converter's flow container back into an empty state. In addition to the above features, based on some of the discussion that was going on in this Forum thread regarding the Filler (or Emptier) being more flexible dealing with possible round-off calculations, a new 'Stop Early Event Name' property may be found on those two objects in Sprint 102. The 'Stop Early Event' feature on the Filler & Emptier objects will allow you to define an optional event that will end the filling or emptying operation early (before reaching the desired fill or empty target) if the specified event occurs. If, for example, you have a Tank supplying a Filler, you might specify that the Filler should stop filling the current container entity if the container becomes full OR if the tank becomes empty, whichever event occurs first. This type of logic would ensure that the container entity is always going to finish the filling operation and exit the filler, even if say there is a scenario where the container entity's capacity was 0.2 but the contents in the tank was 0.199999, the tank would go empty and the filling operation would be considered completed. Thanks again for the feedback on this thread. The input on this forum is appreciated, and we often use information here as input into possible new enhancements and design evaluations.
  6. Just a note that in Simio Sprint 102 software, the TableName.PropertyName.RandomRow function will have been fixed to respect primary-foreign key relationships. Thus, if the executing token or associated object as a reference to a selection set into the table, then the 'RandomRow' function will return a random row index just within the related row set, not an index into the entire table.
  7. Mark: Specifically for the Flow Library Filler & Emptier objects, what I will probably do is add something like a 'Stop Early Event' option, where you can optionally specify to stop the filling or emptying operation early if some specified event occurs. Then in the Filler for example, you could specify to fill the container entity until full or until the source tank is empty (i..e, the tank's 'FlowContainer.Empty' event occurs). Whichever of those events happens first. In your sort of model, that kind of simple approach would guarantees the container is 'filled' and exits the Filler regardless of round-off error. If your fill target is 2.0 and there is only 1.99999999 in the source tank, then the tanks goes empty first and the filler stops. If there is 2.000000000000001 in the source tank, then the container entity full event happens first and the filler stops. Either way, the container entity is exiting the filler and away it goes. Now, in the above latter case where there was 2.00000000000001 in the source tank, of course then you might have some tiny residual left in the tank after the filler is done. In that case, what I have been considering is adding an 'Auto Destroy Contents Mode' to the Flow Library Tank, which allows you to auto-destroy the tank's contents if some specified event occurs and perhaps a condition is also true. Thus, for example, you might want to auto-destroy a tank's contents if the inflow entity type is changing and new product is entering the tank (to 'clean' the tank). In this filler case, when the container entity exits the Filler, you might want to have the Tank be notified of that event and then check if there is some tiny amount still in the tank and if so then just automatically destroy it. If I put in features like above, I think you'd be able to model your flow transfer situations using the Flow Library Tank and Flow Library Filler for example without having to worry about any EPSILON tricks to account for round-off error. And the above are generally the type of features that I lean towards. Getting into Simio's flow engine itself artificially adjusting flow quantities by small epsilon amounts to try to deal with possible round-off errors doesn't feel so good.
  8. Mark, when you replied to 'Glen' did you mean me? We have a 'Glen Wirth' and then me (Glenn Drake!). Small company but they have to hire two Glen(n)s just to occasionally confuse us ha ha. Totally separate note, today I looked at that possible issue with using Filler and the Emptier objects in the Flow Library to possibly deal with floating point round off error issues automatically, and tried a few things, but found nothing that felt really good to actually put in there. Simple example, if you have a Tank with 1.0 cubic meters, and then an attached Filler object removes flow from that tank in 0.2 cubic meter increments...then what happens on my machine is 1.0 - 0.2 - 0.2 - 0.2 - 0.2 - 0.2 = 1e-16 (more or less). Now, after that fifth container entity got filled, you might expect the Tank to be at 0.0, but instead that 1e-16 is still in there. If you then actually have those 5 filled container entities, in the same model, go and empty their contents into a second Tank using an Emptier...then on my machine I see 0.2 + 0.2 + 0.2 + 0.2 + 0.2 = 1.0000000000000009 (or something like that) added to the Tank. Again floating point math error. Adding up 0.2 five times does not equal 1.0. This kind of stuff is incredibly difficult to try to deal with automatically. Generally, there is a rule in trying to clean up round-off errors in general purpose code that if 'You don't know what you don't know' then to tread carefully. I could start trying to put in EPSILON tricks but that is invariably like throwing darts at a dartboard. Not only guessing what a 'good' epsilon value might be but also the fact that round-off errors might be a little bit less or a little more and in a variety of situations (as illustrated in my simple example above). Usually, I try to avoid like the plague getting into EPSILON stuff. I'm always looking for cleaner ways to correct round-off (i.e., situations where the true value is very clear and thus the variable can be simply forced to that value without any kind of epsilon related checking). We can keep thinking about this, but for now, if you are doing flow transfers involving discrete quantities of fluid/mass that need to be 'exact', but round-off error calculations are sometimes throwing a wrinkle either into logic or into animation, then for now all that I can recommend is to put in extra process logic checks as convenient and necessary to deal with such things. For example, in my above example, after filling the 5th container then making sure any residual flow left in the source Tank is destroyed. Or, if possibly the flow quantity in the source tank is 0.999999999999999 when you really need it to be '1.0', because there was round-off error when the flow was added to the tank, then perhaps setting quantity variables accordingly to make sure the flow transfer is still successfully completed. I know this can be a bit painful depending on the situation. This continuous flow stuff can certainly be a bit of pain at times compared to simulation discrete items due to floating point arithmetic...we'll keep working hard on it and beating on it and gradually improving stuff when we can.
  9. The property design of the Flow Library Tank object, for user simplicity, assumes either a flow contents unit type of 'Volume' or 'Weight'. The tank's initial capacity, as well as the tank level mark locations, are then specified in either volume or weight units. The tank was designed this way under the assumption that normally a user has a tank capacity (and level marks) specified in either volume or weight. Not both and not with two distinct volume and weight capacity constraints at the same time. If an advanced user wants to model a Flow Library Tank object with both volume and weight capacity limits, that of course is still possible. Simply assign the TankName.FlowContainer.CurrentVolumeCapacity and/or TankName.FlowContainer.CurrentWeightCapacity state variables using an Assign step in process logic (perhaps in run initialization logic or can be dynamically during the run at any time). All the Flow Library Tank's properties are doing is on run initialization setting one of those capacity constraints to the specified value and then the other capacity constraint to 'Infinity'. But you can re-assign both capacity constraints to your own values in logic if you want. Using those provided state variables.
  10. Just a note that in Sprint 101, the Flow Library Tank object has been enhanced to provide a 'New Inflow Entering' add-on process trigger as well as new built-in 'On New Inflow Entering' state assignment options. The 'New Inflow Entering' add-on process trigger occurs when a new inflow is starting to enter the Tank object, which may be either the first inflow into an empty tank or a change in the inflow entity type into a partially full tank. Note that a token executing this add-on process will be associated with the flow entity that is entering the tank. Also, if the logic of the specified process includes any delays, then the inflow rate into the tank will be halted until the process has completed. You will be able to use these new features to easily assign state values of a flow entity entering the tank, such as its Priority state value.
×