Capacity of factored-customer INDIVIDUAL models are incorrectly scaled

[jecollins]

DefaultUtilityOptimizer.useCapacity() is invoked in each timeslot to compute consumption. For INDIVIDUAL models like Frosty Storage that include multiple individuals, capacity is computed per-subscription (since the individuals may be subscribed to different tariffs) and then scaled by the number of individuals. This appears to ignore the fact that capacity usage could vary across subscriptions, depending on tariff terms for example.

[jecollins]

The scaling happens in CapacityAccumulator.scale() where not only the capacity but also regulation capacity is scaled. This should also be computed per-subscription.

[jecollins]

This appears to be an error. If we look at FrostyStorage.xml, we see that the CapacityBundle has a count of 3 and a population of three. Does this mean there are 9 warehouses, or three? It's not clear. But if we look at the code in DefaultCapacityBundle (which is the only implementation of CapacityBundle), we see that there is a clear expectation that population = count is the usual case for all-individual models, and that each instance as indicated by count corresponds to a single instance of the population. Therefore, the scaling definitely appears to be incorrect.

[jecollins]

It's more complicated. FrostyStorage has a single DefaultCapacityBundle named "FrostyStorage" that has count = 3 and population = 3. There are three CapacityStructure instances named "FrostyStorage1", "FrostyStorage2", and "FrostyStorage3". On the other hand, WindmillCoop has two DefaultCapacityBundle instances named "WindmillCoop-1" with count = 1 and population = 50, and "WindmillCoop-2" with count = 1 and population = 40. Note the difference in naming conventions. All of these named structures are listed in src/main/resources/properties.xml.

But these naming conventions are also hard-coded:

• in DefaultFactoredCustomer.initialize() CapacityBundle names are assumed to be suffixed with "-n".
• in DefaultCapacityStructure.initialize() CapacityStructure names are assumed to be suffixed with "n".

So the names of CaacityBundles and CapacityStructures have to match in propoerties.xml, in the code, and in the individual config filenames. Ouch! Why not just include an index in the xml and an obvious interpretation (or perhaps an indexed array) in the code?

It appears that the 90 WindmillCoop instances are supposed to be treated individually in terms of subscribing to tariffs and computing capacity. Do we gain anything by this individual treatment? Is the sum of 5 draws from a single distribution different from a single draw multiplied by 5?

[jecollins]

The best solution might be to remove the "individual" models from factored-customer and re-implement them as simulation models rather than as statistical models. Good examples are the ColdStorage and LiftTruck models in the customer-models module.