Anti-Patterns

Engines that create 1000s of tasks that each take a fraction of a second to complete. An engine that creates 400,000 tasks may take 20 minutes to complete if 4,000 tasks each with instruction to complete 100 subnets can be completed in five minutes. Time wasted in the managing of tasks is not a joke.

Engines that don’t pay particular care of data structures. Poorly constructed data can lead to O(n^2) or worse. If you're running on 1000 data points, modern hardware will hide it. But if you are running on 1,000,000,000 data points, then it will not. A task that could be completed in under an hour could take days.

Engines that mix reading and writing data into the process step. This can lead to 1000s of repetitive queries or suboptimal inserts. This can lead to tragic run times.

Scenarios must NOT contain options that the user must not select. Setting an engine to run for ten years and creating a data point for every minute for those ten years will cause the system to crash, so the scenario shouldn’t have allowed these combinations.

Scenarios must NOT contain references to Model Names, Cl ass Names, or other things they would not understand. Oftentimes, Scenarios for older engines draw on old IXM Engine Configs where they might refer to SCC Enhanced Order, or they may refer to class name for a cheap way of providing extensibility. The capping module writes a CreateOrder class and then you add parameters to identify that class. It’s flexible but not appropriate for an end-user.

Best Practices

S cenarios are first-class Models and should be treated as such. They need a nice tailored UI with an inbound interface. A UI upload/download is nice. Custom dynamic enumerations so the user can see nice tailored options.