Initializing help system before first use

Logic Changes introduced by Mosel 5

The new language features introduced by Mosel 5 are largely incremental to the existing functionality and language syntax. However, a few points may require updates to existing Mosel source code.

Dynamic package loading

Packages are now handled like native modules: they are loaded dynamically at runtime when the model is loaded into memory.

In models
In order to maintain the same behavior with Mosel 5 as with Mosel 4, employ imports in place of uses for all packages that are not part of the Xpress Mosel distribution.
  • Make sure to always start with the imports statements, and then the uses statements. This is important if the same package is loaded several times, such as directly via a uses and indirectly through a dependency via imports.
  • If you do decide to work with dynamic packages these must be made available at run time (in particular, this also concerns the BIM files in Xpress Workbench apps.)
In packages

Specify the complete list of uses for all descendants that are used directly by this package.

For example: pkga uses pkgb, pkgb uses pkgc and pkgd

If pkga uses directly some functionality from pkgc it now needs to load this package explicitly, but there is no need for pkga to load pkgd if it does not use it.
Note Do not use imports in packages.
mmjobs

If a model or package loads a package via the mmjobs routine load (e.g. to inspect its annotations) you should now specify the option l for lazy loading to load and inspect only the package itself without any dependencies.

Paths

Previously it was sufficient to specify BIM locations, such as by the BIM prefix -bx, for compilation. Now these files are also required for loading a model (that is, at runtime) if the packages are loaded dynamically. Use the new environment variable MOSEL_BIM or set the control parameter bimprefix within a model.

Array handling

Mosel 5 has two categories of arrays: sparse arrays and dense arrays.
  • Sparse arrays include explicitly dynamic arrays that keep the same behavior as in previous versions, and the new array type hashmap.
  • Dense arrays are all arrays that are;
    • not specifically marked as a sparse array type, namely static arrays (same behavior as in previous versions)
    • not fixed (previously: implicitly dynamic) arrays that are now handled more consistently, always resulting in the same representation independent of index set finalization.

Why is it important to correctly declare the Mosel array type?

Mosel works with several different representations of arrays. The main array types in Mosel 5 are sparse and dense arrays:
  • Sparse arrays only contain those entries that have explicitly been defined.
  • Dense arrays contain ;
    • entries for all indices from their specified index set, or
    • in the case of multi-dimensional arrays, entries for all index tuples resulting from the cross product of their index sets—if a particular entry has not been initialized with a value, a default value is used (such as 0 for numerical types.)

Within the two categories of arrays there are several different options:

  • Sparse arrays can be either dynamic (same behavior as with Mosel 4) or hashmap (new type in Mosel 5)

  • Dense arrays do not have any particular markers, they are static if all index sets are constant or finalized at the point where the array is created, otherwise if the index sets are non-constant and not finalized then the array is not fixed.

The case of not fixed arrays was handled differently by previous Mosel versions as opposed to Mosel 5: these typically resulted in implicitly dynamic arrays that were handled more like arrays with an explicit dynamic marker. Mosel 5 removes this ambiguity: if an array is not explicitly marked as a sparse array type it will now always be handled and represented as a dense array. As a consequence, any existing Mosel code that relies on the implicitly dynamic property of arrays (by using create or exists on arrays that do not have an explicit dynamic marker) must now declare this array explicitly as dynamic.

  • Arrays for which index sets are not known at their declaration and that are not marked as dynamic or hashmap are now always represented as dense arrays independently of whether the index sets have been finalized (whereas previously they were represented as sparse arrays if the index sets were not finalized, and otherwise as dense arrays). 
    Mosel3 or Mosel4
    		 
    Mosel5
  • All entries corresponding to defined index values are created at once: previously, dynamic index sets entries were only created for assigned values. 
    Dynamic index sets entries only for assigned values
  • Arrays grow if index sets increase in size. 
    Index sets increase
  • There is no longer any need to use create on arrays containing mpvar variables if the array is not explicitly defined as dynamic. 
    create not required if array is not dynamic
  • Use finalize on index sets in order to prevent the creation of additional (unwanted) entries. 
    finalize index sets
  • Use sparse (dynamic or hashmap) arrays when performing tests with exists, and also to prevent the creation of undesired entries, such as when used for completion of ranges. 
    Sparse arrays with exists
  • Use sparse arrays if you wish to delete entries with delcell or (new in Mosel 5) reset. 
    Sparse arrays with delcel

Stricter syntax checks

Stricter syntax checks may reveal programming errors in certain cases.

The requirement for the public marker is now made strict.
  • The Mosel postprocessing API (C, C#, Java etc.) function XPRMfindident no longer works for entities that are not explicitly declared as public.
  • When a user (record) type definition is public, all types used for fields in this record definition must be public (even if the fields themselves possibly are not public.)
The duplicate use of loop indices is no longer possible.
For example: 
forall(f in union(f in Lsf) {f})
is not permitted—instead use 
forall(f in union(ff in Lsf) {ff})
Package names (that is, the name of the package BIM file) are identifiers. Whilst these names were previously not actively used, employing the same name for a package and for an entity, type, or subroutine is no longer possible.

Compilation options

The Mosel compiler by default now uses the strip -s compilation and the previous default mode that was keeping entities private has been removed. There will be no change in behavior if you are using the -s compilation option for deployment/generation of production versions of your Mosel models following the standard recommendations for application deployment. However, if you have been working with the default compilation settings, this new version might reveal cases where the explicit public marker is missing for entities that need to be visible to external programs (this includes Mosel subroutines employed as call-backs for Xpress Solvers and also any model entities that are accessed from the Insight user interface.)

Parent Topic Migrating to Mosel 5

© 2001-2020 Fair Isaac Corporation. All rights reserved. This documentation is the property of Fair Isaac Corporation (“FICO”). Receipt or possession of this documentation does not convey rights to disclose, reproduce, make derivative works, use, or allow others to use it except solely for internal evaluation purposes to determine whether to purchase a license to the software described in this documentation, or as otherwise set forth in a written software license agreement between you and FICO (or a FICO affiliate). Use of this documentation and the software described in it must conform strictly to the foregoing permitted uses, and no other use is permitted.