optimiser-solver/AMPLSolver.hpp
Geir Horn d2324e42a3 Merge all outstanding changesets
Commit messages as follows:

Change-Id: I631d374144efc540b158868fa65a0bac232a7548
---
Changed the comments for the SLO Violation handler
---
Performance update:
Adding a boolean flag to indicate when all metrics have been set to avoid a linear scan of all metrics on each SLO Violation message.
---
Metric list and reconfiguration wait
Metric updater now listening for a metric list from the Optimiser Controller and not frmo the EMS, and discards SLO Violations until the Optimiser Controller sends a message indicating that the previous application reconfiguration has finished.
---
Log message to indicate that the "reconfiguration done" even message has been received
---
Added the right topic for the metric list
---
New messages
Metric list from the controller
New message format for AMPL model definition
Fixed the AMQ message property settings
2024-04-17 14:27:21 +02:00

327 lines
13 KiB
C++

/*==============================================================================
AMPL Solver
This instantiates the purely virtual Solver providing an interface to the
mathematical domain specific language "A Mathematical Programming Language"
(AMPL) [1] allowing to use the wide range of solvers, free or commercial, that
support AMPL descriptions of the optimisation problem.
The AMPL problem description and associated data files are received by handlers
and stored locally as proper files to ensure that the problem is always solved
for the lates problem descriptions received. When the actor receives an
Application Execution Context message, the AMPL description and data files will
be loaded and the appropriate solver called from the AMPL library. When the
solution is returned from AMPL, the solution message is returned to the sender
of the application execution context message, typically the Solution Manager
actor for publishing the solution to external subscribers.
References:
[1] https://ampl.com/
Author and Copyright: Geir Horn, University of Oslo
Contact: Geir.Horn@mn.uio.no
License: MPL2.0 (https://www.mozilla.org/en-US/MPL/2.0/)
==============================================================================*/
#ifndef NEBULOUS_AMPL_SOLVER
#define NEBULOUS_AMPL_SOLVER
// Standard headers
#include <string_view> // Constant strings
#include <string> // Standard strings
#include <list> // To store names
#include <filesystem> // For problem files
#include <source_location> // For better errors
#include <map> // Storing key-value pairs
// Other packages
#include <nlohmann/json.hpp> // JSON object definition
using JSON = nlohmann::json; // Short form name space
// Theron++ files
#include "Actor.hpp" // Actor base class
#include "Utility/StandardFallbackHandler.hpp" // Exception unhanded messages
#include "Communication/NetworkingActor.hpp" // Actor to receive messages
#include "Communication/PolymorphicMessage.hpp" // The network message type
// AMQ communication files
#include "Communication/AMQ/AMQjson.hpp" // For JSON metric messages
#include "Communication/AMQ/AMQEndpoint.hpp" // AMQ endpoint
#include "Communication/AMQ/AMQSessionLayer.hpp" // For topic subscriptions
// NebulOuS files
#include "Solver.hpp" // The generic solver base
// AMPL Application Programmer Interface (API)
#include "ampl/ampl.h"
namespace NebulOuS
{
/*==============================================================================
AMPL Solver actor
==============================================================================*/
//
// The AMPL solver is an Actor and a Solver. It provides handlers for messages
// defining the problem file and data file(s), and responds to an application
// execution context message by optimising the saved problem for the given
// context parameters.
class AMPLSolver
: virtual public Theron::Actor,
virtual public Theron::StandardFallbackHandler,
virtual public Theron::NetworkingActor<
typename Theron::AMQ::Message::PayloadType >,
virtual public Solver
{
// --------------------------------------------------------------------------
// Utility methods
// --------------------------------------------------------------------------
//
// Since both the optimisation problem file and the data file(s) will arrive
// as messages containing the file name and the then the content of the file
// as a long text string. The following file will open the file for writing
// and save the content string to this file.
private:
const std::filesystem::path ProblemFileDirectory;
std::string SaveFile( std::string_view TheName,
std::string_view TheContent,
const std::source_location & Location
= std::source_location::current() );
// There is also a utility function to look up a named AMPL parameter and
// sets it value based on a JSON scalar value.
void SetAMPLParameter( const std::string & ParameterName,
const JSON & ParameterValue );
// --------------------------------------------------------------------------
// The optimisation problem
// --------------------------------------------------------------------------
//
// The problem is received as an AMPL file in a message. However, the AMPL
// interface allows the loading of problem and data files on an existing
// AMPL object, and the AMPL API object is therefore reused when a new
// problem file is received. The problem definition is protected so that
// derived classes may solve the problem directly.
protected:
ampl::AMPL ProblemDefinition;
// The problem is loaded by the handler defining the problem. This receives
// the standard optimisation problem definition. Essentially, this message
// contains one tag, the name of the AMPL file and the body is a big string
// containing the file content.
virtual void DefineProblem( const Solver::OptimisationProblem & TheProblem,
const Address TheOracle ) override;
// The JSON message received on this topic is supposed to contain several
// keys in the JSON message
// 1) The filename of the problem file
// 2) The file content as a single string
// 3) The name of the initial data file
// 4) The content of the initial data file as a single string
// 5) The default objective function (defined in the Solver class)
// 6) An optional constants section containing constant names as keys
// and the values will be another map containing the variable
// whose value should be passed to the constant, and the initial
// value of the constant.
// Since these elements are parts of the optimisation problem message
// whose class cannot be extended to contain these directly, it is
// necessary to scope these keys differently for the compiler.
struct OptimisationProblem
{
struct Keys
{
static constexpr std::string_view
ProblemFile = "ModelFileName",
ProblemDescription = "ModelFileContent",
DataFile = "DataFileName",
InitialisationData = "DataFileContent",
DefaultObjectiveFunction = "ObjectiveFunction",
Constants = "Constants",
VariableName = "Variable",
InitialConstantValue = "Value";
};
};
// Finally, no solution will be produced unless the problem has been
// defined. A flag is therefore set by the message handler indicating
// that the problem has been defined.
private:
bool ProblemUndefined;
// The AMPL problem file can contain many objective functions, but can be
// solved only for one objective function at the time. The name of the
// default objective function is therefore stored together with the model
// in the above Define Problem handler. If the default objective function
// label is not provided with the optimisation problem message, an
// invalid argument exception will be thrown.
std::string DefaultObjectiveFunction;
// To set the constant values to the right variable values, the mapping
// between the variable name and the constant name must be stored in
// a map.
std::map< std::string, std::string > VariablesToConstants;
// --------------------------------------------------------------------------
// Data file updates
// --------------------------------------------------------------------------
//
// The message defining the data file is a JSON topic message with the same
// structure as the optimisation problem message: It contains only one
// attribute, which is the name of the data file, and the data file
// content as the value. This content is just saved to the problem file
// directory before it is read back to the AMPL problem definition.
public:
class DataFileMessage
: public Theron::AMQ::JSONTopicMessage
{
public:
// The data files are assumed to be published by the performance module
// on a dedicated topic topic for the running solvers.
static constexpr std::string_view AMQTopic
= "eu.nebulouscloud.optimiser.performancemodule.data";
// The received message will be a mapp supporting the following keys
// basically defining the data file name and its content.
struct Keys
{
static constexpr std::string_view
DataFile = "DataFileName",
NewData = "DataFileContent";
};
DataFileMessage( const std::string_view & TheDataFileName,
const JSON & DataFileContent )
: JSONTopicMessage( AMQTopic,
{ { Keys::DataFile, TheDataFileName },
{ Keys::NewData, DataFileContent } } )
{}
DataFileMessage( const DataFileMessage & Other )
: JSONTopicMessage( Other )
{}
DataFileMessage()
: JSONTopicMessage( AMQTopic )
{}
virtual ~DataFileMessage() = default;
};
// The handler for this message saves the received file and uploads the file
// to the AMPL problem definition.
private:
void DataFileUpdate( const DataFileMessage & TheDataFile,
const Address TheOracle );
// --------------------------------------------------------------------------
// Solving the problem
// --------------------------------------------------------------------------
//
// The real action happens when an Application Execution Context message is
// received. This defines the values of the independent metrics used in the
// objective functions and in the problem constraints, and one objective
// function name indicating which objective to optimise. The actual solution
// is provided by a small helper function. The reason is that this may
// use the AMPL problem but not the solver, and as such other solvers can
// be build on this class. The standard definition just asks AMPL to call
// the solver.
protected:
virtual void Optimize( void )
{ ProblemDefinition.solve(); }
// The handler for the application execution context will first set all the
// parameter values for the contex metrics to the received values, and then
// optimise the problem. When a solution is found it will be sent back to
// the Agent providing the application execution context as a solution value
// message. The message format is defined in the Solver base class.
virtual void SolveProblem( const ApplicationExecutionContext & TheContext,
const Address TheRequester ) override;
// --------------------------------------------------------------------------
// Constructor and destructor
// --------------------------------------------------------------------------
//
// The AMPL solver requires the name of the actor, an AMPL environment class
// pointing to the AMPL installation directory. If this is given as empty,
// then the path is taken from the corresponding environment variables. There
// is also a path to the directory where the optimisation problem file will
// be stored together with any required data files.
//
// Note that the constructors are declared as explicit because in theory
// a string could be converted to an Environment class or a Path and so to
// be able to distinquish what a string means, the actual classes must be
// given constructed on the content string.
public:
explicit AMPLSolver( const std::string & TheActorName,
const ampl::Environment & InstallationDirectory,
const std::filesystem::path & ProblemPath,
std::string TheSolverType );
// If the path to the problem directory is omitted, it will be initialised to
// a temporary directory.
explicit AMPLSolver( const std::string & TheActorName,
const ampl::Environment & InstallationDirectory,
std::string TheSolverType )
: AMPLSolver( TheActorName, InstallationDirectory,
std::filesystem::temp_directory_path(), TheSolverType )
{}
// If the AMPL installation environment is omitted, the installation directory
// will be taken form the environment variables.
explicit AMPLSolver( const std::string & TheActorName,
const std::filesystem::path & ProblemPath,
std::string TheSolverType )
: AMPLSolver( TheActorName, ampl::Environment(), ProblemPath, TheSolverType )
{}
// Finally, it is just the standard constructor taking only the name of the
// actor
AMPLSolver( const std::string & TheActorName )
: AMPLSolver( TheActorName, ampl::Environment(),
std::filesystem::temp_directory_path(), "couenne" )
{}
// The solver will just close the open connections for listening to data file
// updates since the subscriptions for the problem definition will be closed
// by the generic solver
virtual ~AMPLSolver();
};
} // namespace NebulOuS
#endif // NEBULOUS_AMPL_SOLVER