[kepler-dev] Build Broken (by MatlabExpression.java?)

Nandita Mangal nmangal at sdsc.edu
Tue Apr 25 23:55:02 PDT 2006


As Christopher also suggests , I guess starting the application from 
matlab's own jvm might be a better solution in this situation.
The only issue might be in automated worfklows (like the ones running 
behind the scenes and computing results) using matlab where
no user is there to start kepler from matlab...maybe there is a 
workaround that , that i can't think of right now?

Currently the windows version is so much of a hack :)  that its almost 
getting impossible
to control the matlab process and add more features to the matlab actor 
in future for optimization/ improving time performance purposes.

Tristan : If you could also take a look at the KEPLER_DOCS/codeReviews 
for some desired features in matlabActor,that would be great.We made
this document during one of our weekly code review meetings. I would be 
working on adding some of the short term fixes from the above doc.

thanks,
nandita.

Tristan King wrote:

> Indeed the delay of starting matlab would become quite a problem 
> (especially on older machines. just launching kepler itself on my 
> ibook is a pain, i've not yet been gaim to install matlab on it and 
> test that out :|).
>
> The problem with starting one matlab process from a singleton and 
> calling that each time we need matlab results is that it wont work 
> under windows. The lack of stdin and stdout streams with windows 
> matlab is the reason we had to use the -r and -logfile options to 
> perform input and output, and these can't be used in realtime, they 
> have to be set when matlab starts. We could do it under unix based 
> systems, but windows is in it's own league.
>
> It might be worth looking into running kepler from within matlab's 
> JVM. I'm not too fond of the idea of this, but we're starting separate 
> matlab processes to get results anyways so it's not like we can 
> actually separate the two. And anyone who's using matlab in their 
> workflows most likely wont mind running things from within matlab, 
> especially if it's simple and fast.
>
> Nandita Mangal wrote:
>
>> A launcher program from Matlab to start Kepler/Ptolemy would mean 
>> that Workflow users first start matlab and then run their workflows 
>> with ptexecute
>> or something of that sort?
>> Currently from matlab Expression it takes a good 10-15 secs to start 
>> up matlab. If we have 3-4 matlabExpression Actors in a workflow they
>> will all start their own process and even be more slower. We can have 
>> a singleton class which creates the process once and the 
>> matlabExpression
>> actors can use(share) the Matlab process w/o starting a new separate 
>> process for each actor.
>>
>> nandita.
>>
>> Christopher Brooks wrote:
>>
>>> Using Runtime and Process will likely work fine.  I think the problem
>>> has to do with how the binaries that are loaded by JNI are created.
>>> The problem started appearing under Windows with cygwin with gcc-3.2.
>>> I think the problem is more associated with cygwin than with gcc.
>>> There is a longish message in ptolemy-hackers,
>>>
>>> at 
>>> http://groups.google.com/group/comp.soft-sys.ptolemy/browse_thread/thread/2c2093bbcd3af95d/28b132dc5abba5cd?lnk=st&q=jni+cygwin+ptolemy-hackers&rnum=1#28b132dc5abba5cd 
>>>
>>> or
>>> http://ptolemy.eecs.berkeley.edu/mailing-lists/split/0603/Re:_ptolemy_matlab15 
>>>
>>>
>>> The real solution under Windows appears to be to create a launcher 
>>> program
>>>
>>> A quick test is to run
>>> cd $PTII
>>> ./configure
>>> cd ptolemy/jni/test
>>> make
>>>
>>> Usually the tests will fail under Windows with gcc after gcc-3.2
>>> If you trash your cygwin installatino and install the cygwin from
>>> Ptolemy-3.0
>>> http://ptolemy.eecs.berkeley.edu/ptolemyII/ptII3.0/cygwin.htm
>>> then the tests pass
>>>
>>> I looked at the Mathworks pages and indeed Matlab can call Java code,
>>> but it looks like to call Matlab from Java, one must use JNI, which
>>> is what we do.  Oh well.
>>>
>>> My one concern is that each time your actor fires, it execs a separate
>>> Matlab process.  This could be slow.  However, under Cygwin at least
>>> it works :-)
>>>
>>> I'd like to see this Cygwin/JNI problem solved, but have not had the
>>> time.  I think it requires creating a launcher to launch Ptolemy
>>> or Kepler.
>>>
>>> _Christopher
>>>
>>>
>>>
>>>
>>> --------
>>>
>>>    Interesting,
>>>    My actor uses the Runtime and Process classes, however they 
>>> themselves    use builtin JNI functions.
>>>       If you can get my more info on invoking matlab without JNI 
>>> that'd be great.
>>>       I'm not sure exactly what you mean when you say JNI is broken 
>>> under    windows cygwin. i can run my actor fine from cygwin, it's 
>>> just a shell    after all and uses the same version of java that the 
>>> rest of the system    uses. Maybe it's just that i'm not familiar 
>>> with the environment you're    using it in tho.
>>>       --Tristan
>>>       Christopher Brooks wrote:
>>>    > Hi Tristan,
>>>    >    > The Ptolemy MatlabExpression actor uses the JNI to 
>>> communicate with
>>>    > Matlab.  I don't think a separate process is invoked.     >    
>>> > I have not looked at Matlab lately, though Ernesto Wandeler recently
>>>    > told me he had been able to invoke Matlab via Java and not use
>>>    > JNI.
>>>    >    > JNI under Windows Cygwin is utterly broken.   JNI using 
>>> Microsoft
>>>    > VC++ works.
>>>    >    >    > _Christopher
>>>    >    > --------
>>>    >    >     My bad with that. I always figured that that java 
>>> compliance settings
>>>    in    >     eclipse meant that the code would compile under 1.4 
>>> (or maybe it does
>>>       >     and i'm doing something wrong). I've modified the actor 
>>> now and compi
>>>   led    >     it using 1.4 to make sure it works, and will commit 
>>> it again later on
>>>       >     today (when i'm 100% sure it wont break anything :)).
>>>    >        >     I've looked into the java interfaces that come 
>>> with matlab, and as fa
>>>   r    >     as i can tell they're not much use to us.
>>>    >        >      From what i've managed to figure out, they just 
>>> allow people to writ
>>>   e    >     java classes for use inside matlab's own jvm (i.e. the 
>>> classes must b
>>>   e    >     called from inside matlab), and don't do anything when 
>>> run from a    >     standard jvm.
>>>    >        >     If anyone knows any different, please let me know. 
>>> I'm not a big fan   of    >     the whole spawning additional 
>>> processes to preform these tasks, and e
>>>   ven    >     less of having to parse text output to decipher the 
>>> results. But for   now    >     i don't know of any other way of 
>>> doing this.
>>>    >        >     --Tristan
>>>    >        >     Christopher Brooks wrote:
>>>    >     > BTW - The Ptolemy Matlab expression actor uses JNI to 
>>> communicate
>>>    >     > with Matlab.  I believe there is now a pure Java Matlab 
>>> interface
>>>    >     > which is much more robust than JNI.  I would support 
>>> tossing the
>>>    >     > Ptolemy Matlab expression actor for a non-JNI Matlab actor.
>>>    >     >    >     > Nandita create a MatlabStartScript utility 
>>> that looks like it start
>>>   s
>>>    >     > a remote Matlab process using 
>>> Runtime.getRuntime().exec().     >     > I'm not so sure if this is 
>>> the right thing, since it starts a    >     > separate process each 
>>> time.  It might be better to have a    >     > more integrated 
>>> actor?  However, I'm not sure what the plan is
>>>    >     > for this actor, so there could easily be good uses for it.
>>>    >     >    >     >    >     > _Christopher
>>>    >     >    >     > --------
>>>    >     >    >     >     MatlabExpression code is apparently 
>>> keeping the nightly build f
>>>   rom    >     >     compiling. Would however is working on this 
>>> please fix ASAP!
>>>    >     >        >     >     (And is this different that the Matlab 
>>> actor in PTII ? (which w
>>>   e coul
>>>    >    d    >     >     put in Kepler)
>>>    >     >        >     >     Dan Higgins
>>>    >     >     NCEAS
>>>    >     >     _______________________________________________
>>>    >     >     Kepler-dev mailing list
>>>    >     >     Kepler-dev at ecoinformatics.org
>>>    >     >     
>>> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/k
>>>   epler-
>>>    >    dev
>>>    >     > --------
>>>    >     > _______________________________________________
>>>    >     > Kepler-dev mailing list
>>>    >     > Kepler-dev at ecoinformatics.org
>>>    >     > 
>>> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/keple
>>>   r-dev
>>>    >     >    >        >     --    >     Tristan 
>>> King                            | Ph: (07) 4781 6911
>>>    >     DART project team                       | Email: 
>>> Tristan.King at jcu.edu
>>>   .au
>>>    >     James Cook University                   | Web: 
>>> http://dart.edu.au
>>>    >     Townsville QLD 4814                     | 
>>> http://plone.jcu.edu.au/dar
>>>   t/
>>>    >     Australia                               |
>>>    > --------
>>>    >       --    Tristan King                            | Ph: (07) 
>>> 4781 6911
>>>    DART project team                       | Email: 
>>> Tristan.King at jcu.edu.au
>>>    James Cook University                   | Web: http://dart.edu.au
>>>    Townsville QLD 4814                     | 
>>> http://plone.jcu.edu.au/dart/
>>>    Australia                               |
>>> --------
>>> _______________________________________________
>>> Kepler-dev mailing list
>>> Kepler-dev at ecoinformatics.org
>>> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev 
>>>
>>>  
>>>
>>
>>
>



More information about the Kepler-dev mailing list