[Coin-announce] CMPL v.1.10.0 released

Mike Steglich mike.steglich at th-wildau.de
Sat Jun 28 10:57:03 EDT 2014

Dear COIN-OR community,

I am pleased to announce the release of CMPL 1.10.0.

New main features and change log (full description ->http://www.coliop.org/changelog.html)

CMPLServer and CmplGrid (1.3.0)
		A CMPLServer can now be used in a single server mode or in a grid mode.
		The grid mode extends the single server mode by coupling CMPLServers from several locations and at 
		least one coordinating CMPLGridScheduler to one "virtual CMPLServer" as a grid computing system. 
		For the client there does not appear any difference whether there is a connection to a single 
		CMPLServer or to a CMPLGrid. The client's model is to be connected with the same functionalities 
		as for a single CMPLServer to a CMPLGridScheduler which is responsible for the load balancing 
		within the CMPLGrid and the assignment of the model to one of the connected CMPLServers. 
		After this step the client is automatically connected to the chosen CMPLServer and the 
		model can be solved synchronously or asynchronously. 
		A CMPLGrid can be used for handling a huge amount of large scale optimisation problems. 
		An example can be a simulation in which each agent has to solve its own optimisation problem at 
		several times. An additional example for such a CMPLGrid application is an optimisation 
		web portal that provides a huge amount of optimisation problems.
	Problem waiting queues for CMPLServer and CMPLGridScheduler
		If a problem is connected to a CMPLServer or a CMPLGridScheduler and the number of running problems 
		including the model sent is greater than number of problems that can be solved 
		simultaneously (defined in cmplServer.opt) it does not make sense to cancel the problem. 
		Especially in case of an iterating solving process with a couple of depending problems 
		it is the better way to refer the supernumerary problems automatically to the problem waiting queue.
		For the single server mode the problem queue handling is organised by the CMPLServer 
		whilst in the grid mode the CMPLGridScheduler(s) is(are) responsible for it. In both modes 
		a problem stored in the problem waiting queue has to wait until an empty solving 
		slot is available or the maximum queuing time is reached.

	Changes in CMPLServer script:
		Usage: cmplServer <command>  [<port>] [-showLog] 
				   -start			- starts as single CMPLServer 
				   -startInGrid		- starts CMPLServer and connects to CMPLGrid
				   -startScheduler  	- starts as CMPLGridScheduler
				   -stop            		- stops CMPLServer or CMPLGridScheduler 
				   -status          		- returns the status of the CMPLServer or CMPLGridScheduler 
			port      	 			- defines CMPLServer's or CMPLGridScheduler's port 
			-showLog            		- shows the CMPLServer or CMPLGridScheduler log file (only Mac and Linux)
			New arguments and changes in cmplServer.opt:
				maxProblems = <x>		
					Defines how many problems can be carried out simultaneously. 
					If more problems than maxProblems are connected with the 
					CMPLServer the supernumerary problems are assigned to the problem waiting queue	
				maxServerTries = <x>
					Since CMPLGridSchedulers and CMPLServers have to call server functions mutually 
					it is necessary to ensure a high availability and failover by repeating failed CMPLServer 
					calls whereby the number of tries are specified by the parameter maxServerTries.
				serviceIntervall = <x>	
					Time in seconds between to iterations of the CMPLServer service thread
				schedulerServiceIntervall = <x> 
					Time in seconds between to iterations of the CMPLGridScheduler service thread
				performanceIndex = <x>		
					Assuming heterogeneous hardware for the CMPLServers in a CMPLGrid it is necessary 
					for a reasonable load balancing to identify several performance levels of the invoked 
					CMPLServers. This can be done by the parameter performanceIndex that influences the 
					load balancing function directly. 
				solvers = <solverName1> [<solverName2> ...] 
					Specifies which solvers in the set of the installed solvers can be provided by the CMPLServer. 
				cmplGridScheduler = <url> <maxproblems>
					Specifies the CMPLGridScheduler to which the CMPLServer is to be connected. 
					The first argument is the URL of the scheduler. The second parameter defines 
					the maximum number of problems that the CMPLServer provides to this CMPLGridScheduler. 
					If a CMPLServer should be connected to more than one scheduler one entry per 
					CMPLGridScheduler is required. 	
		pyCMPL (v.1.3.0) and jCMPL (v.1.2.0) 
			For both APIs the CMPLServer client is expanded for the new CMPLGrid mode and the problem waiting queue.
		CMPL (1.10.0)
			New command line arguments due to the new CMPLServer modes:
				-maxServerTries <x>     : maximum number of tries of failed CmplServer calls
				-maxQueuingTime <x>     : maximum time in <x> seconds that a problem waits in a CmplServer queue
			Cmpl script for Mac, Linux and Windows - some minor changes due to the new CMPLServer modes

The Manual is available at http://www.coliop.org/_download/CMPL.pdf.

The Binaries are available at www.coliop.org/download.html.

Source code
can be obtained by checking out the source code using a subversion client.
	   svn co  https://projects.coin-or.org/svn/Cmpl/releases/1.10.0  CMPL

Mailing list and support
If you are interested to get a direct support, to post bugs or to communicate wishes then please use our CMPL mailing list hosted at COIN-OR http://list.coin-or.org/mailman/listinfo/Cmpl

For more information please visit www.coliop.org  and projects.coin-or.org/Cmpl.


Mike Steglich

Cmpl mailing list
Cmpl at list.coin-or.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.coin-or.org/pipermail/coin-announce/attachments/20140628/028ad125/attachment.html>

More information about the Coin-announce mailing list