merging multiple parameter files

[ott2]

In many graph problems there are at least two graphs, a pattern H and a target graph G. Typically the idea is to try an Essence model for all combinations of G and H.

Currently one has to separately generate a parameter file for each pair of G,H to be investigated. This requires something like a script in which calls to Conjure are prefaced with a merging together of the two parameter files into a single file for Conjure to process.

Currently, if Conjure is passed multiple parameter files then it will run Savile Row with each parameter file in turn. It would be helpful if Conjure were to also support merging multiple parameter files into a single intermediate parameter file, and then using that intermediate parameter file when calling Savile Row or retrieving solutions.

(This assumes that Conjure is intended to be the top level tool in the toolchain.)

[ott2]

A workaround is to call Conjure via a shell script something like the following:

#!/bin/sh
t=conjure-output/inter.param
cp /dev/null $t
while [ "x$1" = 'x-p' ]; do
  shift
  cat $1 >> $t
  q=`basename $1 .param`
  if [ "x$p" = 'x' ]; then
    p="$q"
  else
    p="$p-$q"
  fi
  shift
done
p="conjure-output/$p.param"
mv $t "$p"
conjure solve -ac $* "$p"

Invocation: csp -p 1.param -p 2.param -p 3.param model.essence

(This assumes a basename implementation that supports specifying a suffix to remove, such as the BSD-derived one in MacOS.)

[ozgurakgun]

If we wanted to change the meaning of conjure solve model.essence *.param to "concatenate the param files" that would be trivial to implement.

I guess we would have to decide whether we allow overriding of values or not. I'd like to err on the side of no overrides at a first glance, since depending on the order of param files would be fragile.

Would that be better @ott2? What do you think?

[ott2]

I'm not sure whether the current behaviour should be supplanted.

The non-trivial part of the concatenate semantics is to generate a reasonable name for the intermediate parameter file. It also seems reasonable to require the parameter files to be disjoint at this stage. At a later stage it might be worth supporting mapping names to other names, so that a graph can be defined in terms of N and G but for the second parameter file name N is mapped to n and name G is mapped to H.

[ozgurakgun]

The non-trivial part of the concatenate semantics is to generate a reasonable name for the intermediate parameter file.

Of course we don't actually need to create an intermediate parameter file, right?

[ott2]

No, as long as we have the provenance in the name.

[ozgurakgun]

@cls00 and @JoanEspasa want this as well, we will remove the parallel one and implement a concatenation one.