[seek-kr-sms] Re: [seek-dev] full garp pipeline

[Bertram Ludaescher]

>>>>> "CB" == Chad Berkley <berkley at nceas.ucsb.edu> writes:
>> I guess the fact that there is no actor is on purpose (this seems to
>> be a design workflow, not an executable one).
CB> 
CB> If you mean director instead of actor, then yes.
CB> 

yes, that's what I meant.

>> In the long run, we may actually have a "design director" -- if
>> nothing else, it could do type checking and other static analysis!
>> 
CB> 
CB> that's a good idea.  I'd thought about that a couple times before, 
CB> although I'm not sure if there is a need.  the type system works without 
CB>   a director.

Right. But how about the semantic type checking -- well, ideally it
should become part of the "regular" type checking.
Another try: what about scheduling? Now this needs a
director. But we can probably reuse the existing directors, if you
implement your generic design/blank-slate actor (and its instantiated
versions) in such a way that they output some (fixed or generated)
gobbledygook, just for the purpose of simulating the actual execution
... 

>> Also: why do you call this "dynamic source"?
>> Is this because you want to plug in the code into the "design actors"
>> later?
CB> 
CB> it's just called dynamic source because that's what I called it when I 
CB> build the new actor wizard.  it's probably a bad name at this point and 
CB> should be changed.

ok. How about "design actor" or "stub actor" or "blank actor" or... ?

I think design is good since it indicates what it is used for.

>> Finally, 1 or 2 months for the installer sound good -- Kepler-2-Go;
>> here we come =B-)
CB> 
CB> coded by Bertram :)

almost. But I only make the suggestions here ;-)

Bertram

PS But I'm working on the shipping and handling (SHA) algebra right
now. Here is what a few lines of Prolog output:


y at c = f at a(x at b) -->
[x at b -> a, @a: y = f(x), y at a -> c]
[f at a => b, @b: y = f(x), y at b -> c]
[x at b -> c, f at a => c, @c: y = f(x)]

This is for Grid stuff: it says that for executing the code f,
residing at a on dataset x residing at b, resulting in dataset y at c, 
you can use 3 different plans: 
1. ship data x to a, execute f, then ship the result to c
2. ship code f to b, execute f, then ship result to c
3. ship x and code f to c,  execute f.

the "->" is data shipping, the "=>" is code shipping. 
Of course optimizations are possible, based on whether additional
copies of x,y,z, or f are around. 

Also, this becomes an interesting optimization problem when longer
plans are created... thinking ... ;-)


CB> 
>> 
>> Bertram
>> 
>> 
>> 
>>>>>>> "CB" == Chad Berkley <berkley at nceas.ucsb.edu> writes:
>>>>>> 
CB> 
CB> Hi,
CB> I've put the GARP pipeline we developed last week in SEV up on my web 
CB> site for anyone to download.  Note that this pipeline does not run, but 
CB> is a prototype of the entire GARP process.  There are two files you 
CB> need.  First get http://trestles.nceas.ucsb.edu/full-garp.xml.  You can 
CB> save this file anywhere...I recommend in your kepler directory.  Then 
CB> get http://trestles.nceas.ucsb.edu/dynsrc.tar.gz.  This file will need 
CB> to be unzipped into your kepler directory.  The directory structure 
CB> after you unzip it should be 
CB> kepler/dynsrc/org/ecoinformatics/seek/workflow/.  All of the needed 
CB> actors should be in that directory.  Let me know if you can't get this 
CB> to work.
CB> 
CB> In case any of you want to fix the bug we discovered where the garp 
CB> pipeline window gets created off the screen, edit the file 
CB> kepler/lib/garpModel.xml.  Edit the file and find the line that says 
CB> something like
CB> <property name="_windowProperties"...  on that line there should be an 
CB> xml attribute that looks like
CB> value="{bounds={1300, 2700, 975,590}}".  Change the first two values 
CB> (they may not be 1300 and 2700 but they will be rather large) to 10,10. 
CB> Then execute 'ant clean run'.  the next time you open the garp model 
CB> it should be on the screen in front of you instead of off in 
CB> neverneverland.  let me know if you have problems.
CB> 
CB> Thanks to everyone that was at SEV for the BEAM/AMS/KR meeting last 
CB> week.  It was extremely productive and I think our software projects, 
CB> specifically kepler, will benefit tremendously.  I'll let everyone know 
CB> when I get various things working/fixed in kepler and hopefully we'll 
CB> have an installer within the next month or two.
CB> 
CB> chad
CB> 
CB> _______________________________________________
CB> seek-dev mailing list
CB> seek-dev at ecoinformatics.org
CB> http://www.ecoinformatics.org/mailman/listinfo/seek-dev
CB> 
CB> 
CB> -- 
CB> -----------------------
CB> Chad Berkley
CB> National Center for
CB> Ecological Analysis
CB> and Synthesis (NCEAS)
CB> berkley at nceas.ucsb.edu
CB> -----------------------