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.
If progress updates are done very frequently then it can have a negative influence on the performance. If progress updates are rare, it can take minutes before the progress window is updated again. As a side effect, AIMMS can become seemingly non-responsive, as progress updates are often the only times during a solve in which the solver will give the control back to AIMMS for a brief moment, such that AIMMS can update pages, check for interrupts, etc. (The control is also given back to AIMMS if a callback procedure is called, or during function or derivative evaluations while solving a nonlinear problem.)
Basing progress updates on the number of iterations has some drawbacks. First, the number of iterations completed per second during a solve depends heavily on the problem, solver and algorithm used. Doing a progress update every 100 iterations may be fine for a small or medium sized problem but is likely not sufficient for a large problem. Second, during some steps of the solving process the number of iterations might not change. For example, during the preprocessing step or the calculation of an irreducible infeasible set (IIS). In that case we would not see any progress updates if we would base them only on iterations. Third, for some solvers it is not possible to base progress on the number of iterations. For example, BARON bases progress on the number of nodes, while CP Optimizer uses branches, choice points or failures instead of iterations.
In AIMMS 4.6 progress updates will, by default, be based on elapsed time. The main advantages are that (1) it is supported by all solvers, (2) it can be used even if the iterations count is not changing during some phase of the solving process, and (3) it is problem and solver independent, meaning that you do not have to change any progress option setting if you build a new model or switch solvers. The new option will be named Progress Time Interval. The old Progress Solution option will still be available but it will become inactive by default. It will be possible to combine both options such that progress updates are based on time and iterations.
Note that even after this change there is no guarantee that you will see progress updates regularly all the time. Doing progress window updates requires that the solver passes updates to AIMMS, which does not always happen.
Encryption is typically used to protect the intellectual property (IP) in your AIMMS model and libraries. Access to your application can also be restricted in both AIMMS 3 and AIMMS 4; though the methods differ between the two AIMMS versions.
In AIMMS 3, you had the option to encrypt your project in such a way that it was always stored encrypted, even during development. The benefit is that you could send everything you had to an end-user and you didn’t have to worry about them getting access to the source. Alternatively, you could send them just one or two encrypted libraries. Of course, the disadvantage in AIMMS 3 is that you had no option to do code comparison and/or version control.
As of AIMMS 4, all project sources are text-based. This allows you to use version control software. As a result, the model is no longer stored encrypted and explicit steps are needed to create encrypted code.
This blog posts illustrates how you can create an encrypted project out of the source. The steps required to create an encrypted library will be discussed here as well.
The goal of this article is to explain how you can control errors and warnings within AIMMS. Namely, we will walk you through some useful tips that can help you manage errors and warnings in the best possible way to create better models.
AIMMS started life as a desktop product. Users were mostly individually responsible for looking after their applications, managing the changes, making back-ups, etc. Unwanted incidents such as bugs, accidental project deletion and hardware failures usually had a very limited local impact. Of course mission-critical AIMMS applications were already managed more rigorously.
The advent of AIMMS PRO is introducing new application management challenges as many more users and/or business operations potentially depend on a single PRO platform for performing their tasks. We see our clients looking for ways to professionally operating their PRO platforms. Purpose of this blog post is to provide you with some aspects to consider in this context. We are not proposing anything novel, but merely pointing out some common practices of application management. Continue reading »
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?
AIMMS 4.1 introduces version 14 of BARON. BARON is a solver for solving non-convex optimization problems to global optimality. Version 14 can calculate an IIS for infeasible nonlinear problems including problems with integer variables. To let BARON calculate an IIS, the option Compute IIS should be switched on. BARON offers several algorithms for calculating an IIS, the fastest being a heuristic that “only” calculates an IS (as the infeasible system found could possibly be reduced further). BARON 14 also brings significant improvements in the handling of integer problems. Note that finding a global optimum takes more time than finding a local optimum like most nonlinear solvers do.
Another way to analyze an infeasible problem is by using the Display Infeasibility Analysis option of the AIMMS presolver. This also prints an infeasible set of constraints and variables. In previous versions of AIMMS this set could contain superfluous constraints and variables, but AIMMS 4.1 uses an algorithm to calculate an (almost) irreducible set. Note that the AIMMS presolver cannot always detect that an infeasible problem is indeed infeasible.
Both the Infeasibility Analysis and the IIS, as calculated by BARON, are printed in the listing file.
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 »
A mathematical formula is considered data within an application when it is read in as a string during the application’s runtime, and subsequently used in the construction of selected assignments and constraints. The concept “Formulas as Data” can be applied to several optimization apps, for instance those that deal with “Blending on Specification” and “Asset Management.” In these types of applications, the benefit of the end-users is that they do not have to share these formulas with anyone else, including the developers of the apps. For such apps, good formulas are expensive to develop and having good formulas provides a competitive edge to these end-users. In AIMMS, formulas can be used in the following way:
- String parameters – a formula is a sequence of characters, and such sequences can be stored and manipulated via string parameters. Such manipulation is executed at AIMMS run time.
- Macros – a formula is a mathematical expression and this expression is created during AIMMS compilation time.
The two identifier types, string parameter and macro, effective at different times as far as the AIMMS system is concerned, need to be combined in order to support the concept “Formulas as Data.” How do we go about this? 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 »
Modeling the forest: Ontario’s Ministry of Natural Resources takes us through decades of effective forest management
Forest ecosystems are highly complex and influenced by a diversity of factors. Sustainable forest management is therefore an ongoing and constantly evolving process which requires an integrated approach. Government bodies, such as The Ontario Ministry of Natural Resources (OMNR), must conform to provincial policies and standards, while taking economical and ecological considerations into account to arrive at optimal forest management policies. OMNR manages 27 million ha of Ontario’s public forest and has been using an AIMMS-based model for this purpose since 1994. The Strategic Forest Management Model, or SFMM, enables foresters to analyze the relationships between forest condition, silvicultural practices, wood supply and potential wildlife habitat. This analysis enables them to understand how a forest develops through time and explore alternative forest management strategies and trade-offs. Today, nearly 2 decades after its launch, we spoke with Dirk Kloss, OMNR’s Resource Modeling Specialist, to find out where SFMM stands today and what their experience using AIMMS has been like.