Category archives: App development
The AIMMS WebUI is well known for its capability to create a UI for inspecting and analyzing data in a browser and for modifying existing data. However, as a model developer, you also want your users to be able to:
- Create new data,
- Modify existing data, and
- Detect invalid data as soon as possible
Consider the picture below:
The AIMMS WebUI pivot table displays all numbers, including zeros, always in light blue and on a white background. However, HTML allows us to style each cell in a grid individually to communicate more effectively. How can we leverage this power of communication in an easy to use manner?
The progress window, which can be opened by pressing CTRL-P, allows you to monitor AIMMS during compilation, execution and solving. For example, while solving a MIP problem, AIMMS will display the number of iterations and nodes, the best bound and the best solution in the progress window. So far, progress updates during a solve have been based on the number of iterations used by the solver. By default, the progress window is updated every 100 iterations. This frequency is controlled by the general solvers option Progress Solution.
Some years ago, before Microsoft Office 2010, life was – in some sense – easier for developers: Office was 32-bit, period. In our days, since the release of Microsoft Office 2010, things are a bit more complicated, as users can now have a machine with a 64-bit native version of Office installed as well. This means, for instance, that a 32-bit application using an ODBC driver to connect to an Access database might not work anymore, since the 32-bit ODBC driver might not exist on a machine with a 64-bit Office installation. In such a case, even though the user has a valid Office installation on his or her machine, the application may still display an error regarding the installation or the registration of the proper drivers on the local machine. Continue reading »
The AIMMS webinar of August (2014) dealt with “Analyzing infeasible Problems in AIMMS”. In case you missed it, the recording can be found here. As shown in the webinar, one way to investigate an infeasible problem is by calculating an Irreducibly Inconsistent System (IIS). An IIS is a subset of all constraints and variables that contains an infeasibility. The “Irreducibly” part implies that the subset is as small as possible. Unfortunately, the IIS could only be calculated for linear (and quadratic) problems. So how about nonlinear problems?
In our current AIMMS 4.0 release we have introduced a number of fundamental, and sometimes breaking changes in managing the project sources, about which we got a lot of questions. In this blog post, I will describe these changes and also explain the rationale behind them.
Binary versus text-only source files
In AIMMS 3, all project sources were stored in a binary format. Originally, we introduced these binary files in AIMMS 3 to reduce the total number of files associated with a project. However, over time it turned out that a major drawback of this approach was that the binary format made it very hard to effectively collaborate on an AIMMS 3 project, because the binary files make it really cumbersome to combine the changes made by multiple developers into a new version of the project. For many years, our larger customers have asked us to address this problem, and we partially mitigated it by introducing libraries in AIMMS 3. This allowed multiple developers to work on separate libraries, thus facilitating a limited form of collaboration. Continue reading »
When constructing AIMMS models, we are usually able to handle repetition and structure by adding indexes. For instance, if we have built a model for the conversion process of a single machine, we do not have to duplicate the relevant model code when given an extra machine. Instead, we can use an extra index over a set of machines. However, there are situations where adding an extra index is not an option. This blog post will provide an example of such a situation, illustrating how the issue can be tackled using the AIMMS Model Query and Model Edit functions. Continue reading »
Analytic applications may involve a lot of data and subsequently a lot of computer memory. AIMMS hides the technicalities related to memory management from the model developer. These technicalities include, for instance, the allocation and deallocation of memory for individual data items. Still, the memory usage of applications created with AIMMS grows as the amount of data related to these applications grows. At some point during model development, the memory usage of your application becomes interesting. AIMMS offers tools to monitor and investigate the memory usage of your application. This blog post will delve into some of these tools. Continue reading »
During the evolution of an application, the amount of data it is capable of handling tends to grow. The number of areas in which it can be deployed does as well. When a single data manager file is used to store all this data, the file will grow significantly – even if the data is stored in a compressed form. For applications created with AIMMS 3.12 or earlier versions, there is a 4Gb size limit to data manager files. For applications handling a lot of data, this limit needs to be addressed. Versions of AIMMS from 3.13 onward, use another format for data manager files to which this limit no longer applies. Even though AIMMS 3.13 can read cases from old data manager files and store new cases therein, AIMMS 3.13 does not automatically convert old data manager files to the new format. Luckily, this conversion can be coded in AIMMS. I will demonstrate how in this blog post. Continue reading »