[Os-project-managers] Fwd: Re: Meeting on Wednesday

Mon Dec 5 20:09:00 EST 2011

Kipp Martin <kmartin at chicagobooth.edu> wrote:

>
>
> -------- Original Message --------
> Subject: Re: Meeting on Wednesday
> Date: Mon, 5 Dec 2011 17:27:10 -0600
> From: Jun Ma <majxuh at hotmail.com>
> Reply-To: Jun Ma <majxuh at hotmail.com>
> To: Horand Gassmann <Horand.Gassmann at Dal.Ca>, Kipp Martin  
> <kipp.martin at chicagogsb.edu>
>
> I will get the  layers.pdf.
>
> I feel a bit puzzled by the following sentence. But we can discuss on
> Wednesday.
>> We should introduce  some stronger language there to delineate a bit
>> better who reads what
>
> Talking about layers, first a word on OSI (Open Systems Interconnection
> model, not the COIN Open Solver Interface). OS is not the equivalent of OSI.
> model.
> (The Open Systems Interconnection model is a product of the Open Systems
> Interconnection effort at the International Organization for
> Standardization.
> It is a prescription of characterizing and standardizing the functions of a
> communications system in terms of abstraction layers.)
>
> Rather OS, in a sense,  is one of the layers specified in OSI -- the
> application layer.
> We can of course discuss whether within the OS Protocol, we specify further
> layers. But again, I never even thought of that; nor did I restrict that.
>
> Whereas,  It is natural that the OSI model is layer based  (linearly pack
> from top to bottom), it may not quite apply in OS.
> The OSI model is about VERTICAL technical transport, while OS is about
> HORIZONTAL domain logic.
> For one, the application level logic of optimization process is NOT linear.
> In fact the flow can be anything, e.g. the master optimization launches two
> suboptimization in parallel.
>
> So, it might just be two totally different things between the layers
> mentioned in the OSI model and the OS optimization flow process.
> The goal of OSI is to delineate and restrict and it is possible in that
> area.
> But, is the goal of OS also to restrict and delineate the implementation
> (e.g. how to design the sever-side tiers)? Is it even possible or is it the
> right thing for OS to interfere with?
>
> Today, a tiered server side OS implementation is just our choice of
> implementation. which may have given us the never intended impression that
> OS was designed to be layered.
>
> Again I am not trying to object to anything. In fact, I am more and more
> leaning toward either the simplest design or a very thoughtful "layered"
> design.
> In fact, there is a mentioning of OSfL (OS flow Language) in the original
> thesis. But that was intended to orchestrate different optimization services
> at a higher level than other component OSxLs.
>
> I just hope that we don't confuse between different concepts and just mix
> them together. This should pave the way for our Wednesday discussion.
>
> Jun

Hi Jun,

maybe this is just a mixing of terminology. (I hope it is!) I had  
absolutely no intention of implying any comparison to the layers of  
communications. My point is and was: We have options that pertain to  
the remote system (in the <system> element). These options will not be  
understood by the remote solver, so perhaps they can be stripped out  
before sending the rest on to the next piece of software in the chain.  
Same for <service> and <job> stuff. Only the <optimization> element is  
of any interest to the remote solver. But the OSSolverService is only  
a front for the real solver behind it. It passes along the initial  
values, initial bases, and only those optimization options that have  
"name" attribute matching the solver name. But Couenne, for instance,  
uses Bonmin, and it is possible to want to control Bonmin. This is  
where the "category" attribute comes in. Obviously there is no need to  
pass to Bonmin any options that it does not understand or that were  
dealt with earlier. And Bonmin uses Cbc, and perhaps Clp underneath,  
and it might be advantageous to control their behavior also. We  
devised the colon notation for that. I have been referring to these  
different components in the chain as "layers". Perhaps "levels" would  
have been more appropriate, perhaps there even is a technical term I  
am not aware of.

Anyway, I do think it is important that we get a clear understanding  
that each element in the OSoL file has a unique destination, and that  
players earlier in the chain can look at the option, but are not  
allowed to act upon it. For instance, my OSoL file might contain  
optimization options with name="Glpk". I would *not* want the server  
to pull the plug just because the solver installed on that particular  
system does not have Glpk linked in.

We have an even bigger problem with the OSrL file, because there  
information is written into the file. It must be understood that each  
element in the OSrL file is written by a unique piece in the software  
chain, and nothing *ever* gets destroyed by this.

But before we can give such a guarantee, we must be sure that we agree  
on the elements and their destination. I think layers.pdf will help in  
this process.

Hope this helps rather than hinders the deliberations.

Cheers

gus

>> as you may recall we agreed to meet this week on Wednesday at noon
>> Central. Hope this still works for everybody. Kipp an, I had a long
>> discussion about OSoL today, and I think we finally agreed that  probably
>> OSoL is not such a bad document after all, even in its  current version.
>> However, we also agreed that it would be useful to  get consensus on which
>> layer of the software reads which elements (and  which layer writes to
>> these elements).
>>
>> To that end, we wanted to resurrect our original diagram layers.pdf  (in
>> the figures folder) and see if we can vet it carefully. Jun, can  you make
>> sure to print out this diagram for the meeting on Wednesday;  I think it
>> is essential that we each have a copy in front of us.
>>
>> We also talked about the top level elements in the OSoL schema in this
>> context (first set of bullets in section 3.2). We should introduce  some
>> stronger language there to delineate a bit better who reads what  (and in
>> section 4.2 we should have a similar set of bullets that  spells out more
>> clearly who writes what).
>>
>> Talk to you Wednesday.
>>
>> Cheers
>>
>> gus
>>
>> -------------------------------------------------------
>>
>> Horand I. Gassmann, Professor
>>
>> School of Business Administration, Dalhousie University
>> 6100 University Avenue, PO Box 15000
>> Halifax, Nova Scotia, Canada, B3H 4R2
>> ph. (902) 494-1844
>> fax (902) 494-1107
>>
>> http://myweb.dal.ca/gassmann/
>>
>>
> _______________________________________________
> Os-project-managers mailing list
> Os-project-managers at list.coin-or.org
> http://list.coin-or.org/mailman/listinfo/os-project-managers
>
>

-------------------------------------------------------

Horand I. Gassmann, Professor

School of Business Administration, Dalhousie University
6100 University Avenue, PO Box 15000
Halifax, Nova Scotia, Canada, B3H 4R2
ph. (902) 494-1844
fax (902) 494-1107

http://myweb.dal.ca/gassmann/