allocation error

agoodkind · Post by **agoodkind** » Tue Nov 16, 2010 12:19 am

I have been working on a Vensim model that uses the ALLOCATE AVAILABLE function and I've noticed that there appears to be an error when working with very large numbers. I'm attaching a simple model that demonstrates this. The model has a single input and three firms that compete for the input. The model allocates the input based on the firm's ppriority. There is a 'large number' variable that subtracts from firm 3's ppriority, so when this 'large number' gets larger firm 3's allocation goes to zero. The error occurs when this 'large number' gets much larger. Once the allocation of firm 3 is driven to zero, making the 'large number' larger shouldn't have any effect on the model; however, in the model when the 'large number' gets very large the allocation of firm 1 and 2 changes unpredictably, and can exceed the total amount of the input available. I would be interested to know if anyone has an explanation of this error.

Thanks

Post by **Administrator** » Tue Nov 16, 2010 9:08 am

I cannot see any problems with this model. Can you give me a list of values for "LARGE NUMBER" to try? Or describe the exact steps to see the behaviour you are seeing?

Apart from some small rounding errors, the allocation is identical to the input as well.

Post by **tomfid** » Tue Nov 16, 2010 11:23 pm

I see problems for large_number >= 100e6 roughly. I'm guessing that it's some kind of numerical issue, e.g. a scaling that assumes that the priorities are within a few orders of magnitude of one another.

ALLOCATE is essentially integrating the supply and demand curves, so my guess is that setting a huge negative step size makes the integration step too coarse.

If you're trying to suppress demand for one firm, it's probably better to either work directly on the demand or at least use a limited adjustment to the priority.

Tom

bob@vensim.com · Post by **bob@vensim.com** » Wed Nov 17, 2010 12:36 pm

There is a numerical issue here. The width and priorities need to be the same order of magnitude or the results won't make sense. We will put in a change to throw a nonconvergance message in this case. The fix is to bound the inputs to be of the same order of magnitude (eg all from 0 to 1000).