Upcoming Webinar: Register now >>

Optimizing MATLAB’s Concurrent & Named User Engineering Software Licenses

Subscribe to our blog

Loading

If your company uses MATLAB®, you’re probably familiar with the assorted licensing methods that MathWorks® utilizes to extend access to its applications. Specifically, Individual (node-locked), network named user, and concurrent licenses are available, each offering different benefits, restrictions and price points.

For individual or node-locked licenses, you specify the user, and the application can be installed on up to four computers. This license doesn’t support multiple sessions so users are prevented from operating the program on two or more computers simultaneously.

With a network named user license, you specify the list of possible users. The program may be operated by those individuals on computers served by a single license manager, and up to the maximum number of people on the license. This license doesn’t support multiple sessions either.

A concurrent license enables you to provide application use to anyone with access to your network. Access is not limited to specific named users.

In general, a concurrent license is more expensive than the other two options but it gives companies more flexibility to support larger numbers of users. Moreover, the price per user should be lower because the licenses can be shared.

Mixing License Types and Planning

It’s common for companies to employ a mix of licensing models to best suit their workforce requirements, and to get the most out of their software expenditure. However, the task of planning which users should get the named licenses and which need to share the pool of concurrent licenses is often done without fully understanding the impact of the decision on overall cost. Below are a few common errors that license administrators can easily make.

  1. Assigning a named license to a user who does not actually use it for most of their working day. A named license might initially appear to cost less than a concurrent license but a named license that isn’t used intensively day after day can work out much more expensive than a concurrent license that serves a number of users each at a different time of day. If a named license is given on the basis of seniority or status rather than actual usage requirements then the engineers who really need the software may run out of available pooled licenses while the named license is idle.
  2. Purchasing individual or node-locked licenses that are not network-based. Individual and node-locked Matlab licenses can be purchased to be stand-alone and not need a license manager. This can be advantageous if the workstation is not always connected to the network. However, something that can be overlooked is that the tools required by the team can extend also to include one or more of the many Matlab toolboxes at a considerable extra cost. The toolboxes needed are likely to vary from one user to the next and so one size generally doesn’t fit all. An interesting ‘hybrid’ solution that not everyone knows about is to use concurrent licensed toolboxes with node-locked licenses for the Matlab basic product thus getting the benefits of pooling for some important features. The result is that to optimize license usage, you need to look carefully at how all the licensed features are used and not just the package or main product.
  3. Not checking actual usage on a frequent basis. But perhaps the most important practice to remember when it comes to planning and allocating named licenses is frequently reviewing the actual usage and continually making changes to fit the current situation. An intensive user of a feature this month might have no need for that feature next month, because engineers may need different tools at different stages of a project.

The license manager employed by MathWorks to control and manage the issuing of concurrent and named user licenses over the network is Flexera FlexNet Manager.

License Manager Configuration

FlexNet Manager is configured by editing a text file called the options file and if not performed properly, named users can unknowingly check out more expensive concurrent licenses. This effectively raises the licensing cost and can lead to downtime due to a lack of available MATLAB or other essential engineering software licenses.

You also need to check that the license file is correct and that new license files have been uploaded. This may require renaming and moving files for backup purposes in case of error. This administrative process takes time and, if you judge by the number of configuration questions that show up on vendor support forums, is prone to error.

There are also times when a concurrent license gets issued improperly, even though the named users appear to have been correctly defined. It’s unclear what causes this problem but might be connected to the license file structure and its segmentation into pools. Multiple pools are created in the license file licenses when batches of licenses are purchased at different times.

Each pool can contain one or more license types, but usually only has a single type. By rearranging the order of appearance of pools in a multi-pool license file, you can reduce the chance that a concurrent license is pulled when a named license should have been taken instead.

In any case, whether the licenses are checked out according to the way your organization intended them to be or not, the license manager is concerned primarily with controlling allocation and doesn’t provide the requisite details regarding license usage.

Enhancing the License Manager

License managers provide the basic capabilities for ensuring compliance  according to the licensing agreement but there are specific areas where they can be improved to the benefit of the user organization. That’s where OpenLM can assist. It works in combination with your existing license manager making it easier to configure your named license definitions, and monitor which licenses have been checked out.

With the OpenLM License Allocation Manager extension, you can more easily edit the appropriate options file and define named users by completing a simple input screen that functions like an online form. There is also an option in OpenLM to optimally sort the vendor’s license file so that when the license manager’s selection algorithm receives a request, it’s more likely to fulfill that request accurately. A named user will receive his allocated license instead of being assigned a concurrent one.

Conclusion

Combining MathWorks concurrent and named user licenses can help companies save money on software licensing and ensure that employees have the application access they need. Heavy users will probably require their own named licenses and part-time users can share licenses from the pool on a first-come, first-served basis.

This process works efficiently as long as named users have been configured properly, they pull the appropriate license type, and their use patterns really justify having individual licenses. This mandates proper setting up and prior and ongoing planning together with detailed monitoring of actual usage (as provided by the OpenLM Actual Usage extension).

Skip to content