[Os-project-managers] responsetogus

[Kipp Martin]

-------- Original Message --------
Subject: Re: update
Date: Mon, 9 Jan 2012 18:14:10 -0600
From: Kipp Martin <kmartin at chicagobooth.edu>
To: Horand Gassmann <Horand.Gassmann at dal.ca>

Hi Gus:

A few things:

1) I feel very strongly that the OSCommandLine object should never ever
create an OSInstance. I think the OSCommandLineReader should take the
command line and put the various command line values into a data
structure. In this case OSCommandLine is taking the place of the old
OSOptionsStruc. End of story. That is all it should do. Store what was
on the command line in a convenient fashion so that calling programs can
get at the data.

2) So now there is the issue needing an OSInstance object in both
OSServiceMethods and OSSolverService if you want to print. I don't think
the OSServiceMethods should ever print. I think only OSSolverService
should print.

3) I don't think the OSServiceMethods should ever have an OSInstance.
Why would it ever need it? It takes the oscommandline object and either
does a remote solve, send, or whatever or a local solve. Why does it
need an OSInstance? It certainly can't send an OSInstance over the Web,
and it can call a local solver and give it OSiL.

4) Now for the print problem. Let's take OSSolverService. It passes a
command line string to OSCommandLineReader and gets an OSCommandLine
object back. If there is an OSiL file present, it parses it with an
OSiLReader, creates an OSInstance and prints the model in infix format.

5) It should be the responsibility of the calling program to
create/destroy and OSInstance or do the printing. OSServiceMethods and
OSCommandLine should never be creating an OSInstance. Unless I am
missing something it seems totally unnecessary.

My philosophy is that OSCommandLine, OSCommandLineReader, and
OSSolverServices should be light weight. I am not at all bothered by the
fact the there may have to be some duplication of code in the calling
programs.  I also understand that it could be the case that we do a
local solve in which case an OSInstance is created in the
OSSolverInterface, and a second OSInstance is created in OSSolverService
if we need to do a print. I don't care! I much rather have something
like this and keep the architecture simple. Also, I don't think I have
ever done both a print and solve from the OSSolverService. Is see this
as a nonissue.

Tuesday for me is a teaching, workshop, and faculty recruiting day. Do
you want to talk on Wednesday? Or is that your bad teaching day? I seem
to recall Monday and Wednesday are your teaching days and Tuesday and
Thursday mine.

Cheers




>> It 3:40 AM and I just now finished my class notes. I am too tired to
>> keep going. I really apologize about this. I know you are working hard
>> on this and I want to be on top of it. Things are just crazy right
>> now. I got up this morning and started working first thing. I did not
>> even eat until my faculty dinner. It is just insane. I will try to
>> look at OS as soon as I can.
>
> That's fine. I understand. Let me perhaps try to summarize, in the hopes
> that this might make it easier for you.
>
> First, the problem is that we need an OSInstance object both in
> OSServiceMethods and in OSSolverService (if we want to print something).
> We have been making osinstance a data member of oscommandline, which is
> available everywhere, and is being passed from one routine to the next.
> Since oscommandline also contains an osil string (along with the name of
> the OSiL file), this seemed like a clean extension. (OSOptionsStruc did
> not contain the osinstance, but did contain the osil string.)
>
> We populate the osinstance in the oscommandline element in the
> nonstandard constructor of OSServiceMethods. There we new an OSiLReader,
> read the osil string into the OSiLReader's m_osinstance element (which
> is private), and somehow associate it with the oscommandline object.
>
> I have been doing a shallow copy (duplicating just the pointer), but
> that leads to a segfault, because I need to destroy the OSiLReader at
> the end of the constructor.
>
> Alternatives are:
>
> 1. allocate the OSiLReader in the OSSolverService and pass it around as
> an argument of OSServiceMethods
> 2. make the OSiLReader an element of OSServiceMethods
> 3. make osilreader->m_osinstance a public member, so that I can NULLify it
> 4. write a (public) method osilreader->nullifyInstance() that has the
> same effect
> 5. do a deep copy of osinstance
>
> 5. is my least favorite method. OSInstance objects are large, and
> copying them is going to take lots of time. I think 1. and 2. are the
> only real options, but perhaps there is something I have not yet thought
> of.
>
> Cheers
>
> gus
>


-- 
Kipp Martin
Professor of Operations Research
and Computing Technology
Booth School of Business
University of Chicago
5807 South Woodlawn Avenue
Chicago, IL 60637
773-702-7456
kmartin at chicagobooth.edu
http://www.chicagobooth.edu/faculty/bio.aspx?person_id=12825325568
http://projects.coin-or.org/OS

Sent without Blackberry, Droid, iPhone, or any other
wireless device.
--