graphdraw-opmanager

primal-infeasible

The instance

as published

Variables: 4,812
Constraints: 75,395
Nonzeros: 227,160
Format: MPS, gzipped

Where it comes from

provenance

A branch-and-bound run reached this node's parent and split on a variable. This instance is the side the search did not explore, and it has no feasible point.

branch taken by the search
zV[r,rt,devicepackagetoven...,statsdatasumdaily_20...] ≤ 0
this instance, the other side
zV[r,rt,devicepackagetoven...,statsdatasumdaily_20...] ≥ 1 at depth 293

Depth in the tree: 293
Bounds tightened vs. source: 275
Branch variable: zV[r,rt,devicepackagetoven...,statsdatasumdaily_20...]

Tightened bounds

275 entries

x[r,managedobject]>=37x[r,managedobject]<=37x[r,topoobject]<=39x[r,node]>=39x[r,opmanagerobject]<=38x[r,categorydefinition]>=39x[r,snmpinterface]>=40x[r,ipaddress]>=40x[r,managedobjectid]<=39x[r,protocoldetails]>=45x[r,graphdiagnostics]>=39x[r,graphdiagnostics]<=39

12 of 275 shown. The complete list is in the sidecar.

Also published in the dual-infeasible set view →

Download

graphdraw-opmanager_if.mps.gz1.82 MiB graphdraw-opmanager_if.meta.json6 KiB

The sidecar carries the full provenance, including the fields this page truncates.

Source instance

Namegraphdraw-opmanager

Submitted byCézar Augusto Nascimento e Silva

Groupgraphdraw

TermsCC BY-SA 4.0

general_linearinvariant_knapsackset_partitioningvariable_bound

In the Graph Drawing problem a set of symbols must be placed in a plane and their connections routed. The objective is to produce aesthetically pleasant, easy to read diagrams. As a primary concern one usually tries to minimize edges crossing, edges’ length, waste of space and number of bents in the connections. When formulated with these constraints the problem becomes NP-Hard . In practice many additional complicating requirements can be included, such as non-uniform sizes for symbols. Thus, some heuristics such as the generalized force-direct method and Simulated Annealing have been proposed to tackle this problem. uses a grid structure to approach the Entity-Relationship (ER) drawing problem, emphasizing the differences between ER drawing and the more classical circuit drawing problems. presented different ways of producing graph layouts (e.g.: tree, orthogonal, visibility representations, hierarchic, among others) for general graphs with applications on different subjects. The ability to automatically produce high quality layouts is very important in many applications, one of these is Software Engineering: the availability of easy to understand ER diagrams, for instance, can improve the time needed for developers to master database models and increase their productivity. Our solution approach involves two phases: ( (i) ) firstly the optimal placement of entities is solved, i.e.: entities are positioned so as to minimize the distances between connected entities; and ( (ii) ) secondly, edges are routed minimizing bends and avoiding the inclusion of connectors too close. We present the model for the first phase of our problem.

Source description quoted from MIPLIB 2017; links and mathematical notation formatted for the web.

View on MIPLIB 2017 →