Fluid Object - Controlling Order of Operation

[Bennett Foster]

The Flexsim Fluid Object operating logic recognizes that it is important to control the "order of pull". While the normal order setting algorithm is reasonable, I have occasionally seen plant model results increase by 3x after I resorted the order of operation (by going into the tree and moving fluid objects up and down). This is (presumably) due to the fact that chemical plants often have multiple recycle loops - and Flexsim is hardpressed to determine "where to start".

The Ticker has a check box "optimize object list resorting" which prevents the stock Flexsim algorithm from resorting the order of operation when the box is checked. The problem is that whenever even one more fluid object is added to the model, the Flexsim algorithm for determing order, kicks in and my custom order is lost. (I have to go in and resort the Fluid Objects in the tree by hand again.)

I'd like to see a control swithch such that Flexsim does not ever change the order of operation - except to put the new objects at the top of the list so that the user can keep the sort and just put the new object in whatever order is desired.

[Jason Lightfoot]

Technically this is possible but I'd advise you fully understand the implications of making any alteration to the order of the objectlist entries in the Ticker. To me a three fold increase sounds an alarmingly large difference.

In the objectlist variable you are rearranging, set the number of the new object's row entry in the list to a non-zero before you hit reset (which is when the re-ordering takes place). Then manually alter the position. Changing connections will also make these numbers zero, so again you'd have to change them to a non-zero (and adjust the rank to reflect the connection change) before resetting.

[Bennett Foster]

The 3x increase in rate is real - and was alarming. However, the model result I got after resorting the ticker according to my best judgement (and before putting in any randomness) was within 1% of our ChemE's spreadsheet calculations. One minute I was pulling out my hair wondering why the darn model would not get even close to the "right" answer - and the next minute it nailed it.

I'm not sure what you mean by the "object's row entry". Also, when you change positions, do you need to change the "row entry" for both objects the connection touches?

The view may not be worth the climb for doing it this way. (I currently keep a screen shot of the tree where it should be - and manually resort after making any "structural changes".) But I appreciate your reply - and would like to understand how to do what you've suggested (in case the resort task later becomes more onerous).

[Jason Lightfoot]

Sorry for not explaining very well.

It's just the numeric value of the nodes directly under the objectlist variable - the ones with the object name. The values of those nodes relate to the number of connections away from the Generator.

In my mind (sorry) the ticker's object list is like a table where the row header is the name of the object (the nodes refered to above) and each column cell (underneath those nodes) is a coupling to the object's counterpart node in the '>stored' part of its attributes called 'FluidListLink'. Personally I would have the link attributes under the coupling instead of this way around.