[Dip] Deploy Dip over wireless network?

Matthew Galati matthew.galati at gmail.com
Thu Jan 19 09:16:31 EST 2017


When you say "wireless node" - I assume you are referring to a distributed
set of machines (a grid).

There are two scenarios to consider here:
(1) Building the subproblems (and handling their associated data)
distributed, and
(2) Solving the subproblems in a distributed fashion.

For scenario (2), I have done just this in my commercial product life (at
SAS) here:
http://documentation.sas.com/?docsetId=ormpug&docsetVersion=14.2&docsetTarget=ormpug_decomp_toc.htm&locale=en

One thing, that might be obvious is that the potential speed-up is greatly
burdened by the balance in the difficulty of solving the subproblems. This
gets a little bit easier if you are willing to deal with non-determinism.
But, in a deterministic framework (which is important for commercial
applications), I have found that this paradigm really only works for
special cases. The more generic approach often has one or two subproblems
that dominate the pricing mechanism and very good parallel speedup is
difficult to attain. That being said, it does help quite a bit on some
instances. I think this is a wide open research area for understanding ways
to improve this balance in such an environment by being more clever about
how aggressive you really need to be on the subproblem resolution. I
welcome any and all contributions to this study.

As for DIP, yes - there is no reason at all that the same paradigm
(scenario (2)) would not work. The framework is setup for it. You would
just need someone to work on it. I unfortunately don't have the cycles for
much open source development these days. Ted Ralphs is the lead on DIP now
and may have already thought about this. I'd be happy to consult (as time
permits).

Now - scenario (1) is a different beast all together. On the surface, my
answer would be that "no" - DIP is not really designed for that kind of
implementation. Some of the more specific implementation details assume
that the entire compact formulation (including the subproblems) are in
memory on one machine. This assumptions simplifies quite a bit of the code
workflow. But this is strictly a design issue. There is no algorithmic
necessity for such a thing and I am sure with some work that DIP could be
made to work this way. But, the original design that I worked out did not
have this scenario in mind. I think the other COIN product, BCP did, in
fact, have this concept in mind when it was designed. So - that might also
be worth some investigation.

The other complexity that arises with scenario (1) is assuming that you
wish to use a modeling language to interface with DIP. In that case, the
modeling language itself would need to be able to handle distributed data
and model building on a grid.

Scenario (1) is something that is on my long-term plan for my commercial
work at SAS. But, is currently fairly low priority.

Cheers,
Matthew Galati



On Mon, Jan 16, 2017 at 6:35 PM, Stan Stringfellow <
stan.stringfellow at plasticfog.com> wrote:

> Hi!
>
>
> Can someone answer the following?
>
>
>    - Is it possible to use DIP to deploy DW subproblem instances to
>    separate wireless nodes?
>    - If not, would it be possible to extend the code to handle this
>    deployment scenario? Would that be extremely difficult to do?
>    - Does it make sense to deploy a solution in this way? ...the
>    motivation being that the subproblems could be solved directly on the
>    wireless nodes without uploading large amounts of subproblem data that
>    originates on those nodes to the network core.
>
> I greatly appreciate it!
>
>
> Stan Stringfellow
>
>
> CEO/Founder PlasticFog Group
>
> San Diego, California
>
> Email: stan.stringfellow at PlasticFog.com
>
> Cell: 858-349-7907 <(858)%20349-7907>
>
> _______________________________________________
> Dip mailing list
> Dip at list.coin-or.org
> http://list.coin-or.org/mailman/listinfo/dip
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.coin-or.org/pipermail/dip/attachments/20170119/86366282/attachment.html>


More information about the Dip mailing list