[kepler-users] Interfacing C/C++ to kepler
Ricardo.Pascual at csiro.au
Ricardo.Pascual at csiro.au
Thu Oct 4 17:21:12 PDT 2012
Thanks for the email Edward. It is always difficult to implement when one has to compile code at runtime then run it especially if is in mix-language environment. I will have a look at BCTVB and FMI. Hopefully that will suffice.
Thanks,
Ric
-----Original Message-----
From: Edward A. Lee [mailto:eal at eecs.berkeley.edu]
Sent: Thursday, 4 October 2012 8:54 PM
To: Pascual, Ricardo (CMAR, Dutton Park)
Cc: cxh at eecs.berkeley.edu; Kepler-users at kepler-project.org
Subject: Re: [kepler-users] Kepler: Array instantiation and Array element assignment
The EmbeddedCodeActor might be worth looking at.
There is a demo here:
$PTII/ptolemy/cg/lib/demo/Scale/ScaleC.xml
that has an instance of this actor. If you look inside this actor, you see C code (using some macros for interfacing). When you run the model, it generates a C program, compiles it, links it in, and uses it to give the behavior of the actor.
As Christopher said, this is much more brittle than pure-Java models. The model may not compile for you on your platform. It can also seg-fault, crashing the whole Vergil process. But that's C programming for you...
A more robust way to interface to external code was developed by LBNL (called the Building Controls Virtual Testbed, BCTVB). This is in the PtII tree somewhere, though I can't think where off the top of my head.
We are also working on an FMI interface (see fmi-standard.org).
Edward
On 10/1/12 10:01 PM, Ricardo.Pascual at csiro.au wrote:
> Hi Christopher,
>
> Thanks for the email. Now the fact that that we can interface with C
> /C++ is good news. At the moment I am evaluating a possible framework
> for us to use with our project related to climate model analysis. I
> have used Kepler to create actors related to climate studies using the
> composite actor and they are working well. I am heartened by fact
> that the user group has been very responsive and helpful as I learn
> this framework.
>
> I ended using what you suggested, that is using a Parameter actor that
> can be seen workflow wide. Am I allowed to say "the variable is
> local to the workflow actor" J.
>
> Thanks again,
>
> Ric
>
> *From:*Christopher Brooks [mailto:cxh at eecs.berkeley.edu]
> *Sent:* Tuesday, 2 October 2012 12:00 PM
> *To:* Pascual, Ricardo (CMAR, Dutton Park)
> *Cc:* barseghian at nceas.ucsb.edu; Kepler-users at kepler-project.org
> *Subject:* Re: [kepler-users] Kepler: Array instantiation and Array
> element assignment
>
> Hi Ricardo,
>
> Interfacing to C is not that difficult, though it is difficult to do
> in a portable manner.
> See
> http://docs.oracle.com/javase/7/docs/technotes/guides/jni/
>
> I used JNA (https://github.com/twall/jna) with good success to
> interface to FMI, see org/ptolemy/fmu.
>
> The JNAerator will create stub code for you from C and C++
> http://code.google.com/p/jnaerator/
>
> Ptolemy II includes ways to access C code, see the faq links below.
> See $PTII/bin/vergil $PTII/ptolemy/cg/lib/demo/Scale/ScaleC.xml
>
> For interfacing to a C library that is complex, I suggest using JNA to
> create some wrapper Java code and then write actors that use the Java
> wrapper code.
>
> I don't really understand your initial question though. What are you
> trying to do?
>
> You said you wanted to create a "scope workflow wide". Typically, we
> do this by placing a parameter into a model.
>
> If you were writing Java code, you would create a parameter in the
> container of an actor, but this is not very good actor-oriented programming.
>
> For information about writing actors in Java, see the designing
> actors chapter of
> http://www.eecs.berkeley.edu/Pubs/TechRpts/2008/EECS-2008-28.html
>
> _Christopher
>
>
> On 10/1/12 6:04 PM, Ricardo.Pascual at csiro.au
> <mailto:Ricardo.Pascual at csiro.au> wrote:
>
> Hi Derik,
>
> Thanks for the email. Somehow I need to interface with C/C++ codes
> as there are codes that I will need written in C/C++.
>
> It is good to know that there is an active forum on Kepler.
>
> Cheers,
>
> Ric
>
> *From:*Derik Barseghian [mailto:barseghian at nceas.ucsb.edu]
> *Sent:* Tuesday, 2 October 2012 10:56 AM
> *To:* Pascual, Ricardo (CMAR, Dutton Park)
> *Cc:* kepler-users at kepler-project.org
> <mailto:kepler-users at kepler-project.org> Users
> *Subject:* Re: [kepler-users] Kepler: Array instatiation and Array
> element assignment
>
> Hi Ric,
>
> I found some relevant info here;
>
> http://ptolemy.eecs.berkeley.edu/ptolemyII/ptIIfaq.htm#Interfacing
> to C/C++
>
> <http://ptolemy.eecs.berkeley.edu/ptolemyII/ptIIfaq.htm#Interfacing%20
> to%20C/C++>
>
> http://ptolemy.eecs.berkeley.edu/ptolemyII/ptIIfaq.htm#CodeGen
>
> The descriptions make it sound like these aren't being worked on
> anymore, but I've seen ptolemy SVN check-ins that seem to do w/ C
> code generation and copernicus in the recent past, so I'm not sure
> about that.
>
> Note you can call any arbitrary program using the External Execution
> actor.
>
> If you're trying to develop new actor(s), customizing the
> RExpression or Python actors, or writing new ones in Java is
> probably easiest.
>
> Derik
>
> On Oct 1, 2012, at 8:46 AM, "Edward A. Lee" <eal at eecs.berkeley.edu
> <mailto:eal at eecs.berkeley.edu>> wrote:
>
>
>
>
>
> The SetVariable actor is rather tricky to use.
> Depending on the director that you choose and the parameters you set,
> it could be nondeterministic. Why go through a variable? Why not just
> feed the data from DirectoryListing to where it is needed?
>
> If there are lots of places it is needed, you might consider using
> Publisher and Subscriber. These, at least, are assured of determinism.
>
> It is a bit of a change of mindset to "think in kepler" :-)
> It's quite important which director you pick. They all provide
> a concurrent model of computation, but their behaviors are quite
> different...
>
> Edward
>
>
> On 9/30/12 8:49 PM, Ricardo.Pascual at csiro.au
> <mailto:Ricardo.Pascual at csiro.au> wrote:
>
>
> Hi Edward.
>
> Thanks for the email. I am still trying to to learn how to think
> properly in kepler. Any how the best solution I can come up with
> is defining a parameter actor and setting the value using the
> VariableSetter actor. I believe you created this actor. So if I set
> it to an array of strings dirList will be an array of string as in
> below.
> *dirList #"declare the variable as ParameterActor"
> DirectoryListingActor -----> VariableSetterActor(with .variablename
> =dirList)
>
> There might be a more elegant solution but that will have to wait
> until I know more of kepler. As you pointed out you can do this
> with the various Expression like RExpression and others. BTW is
> there a hook to C++ in kepler?
>
>
> Kind regards.
>
> Ric
> ________________________________________
> From: Edward A. Lee [eal at eecs.berkeley.edu
> <mailto:eal at eecs.berkeley.edu>]
> Sent: Monday, 1 October 2012 7:02 AM
> To: Pascual, Ricardo (CMAR, Dutton Park)
> Cc: Kepler-users at kepler-project.org
> <mailto:Kepler-users at kepler-project.org>; cxh at eecs.berkeley.edu
> <mailto:cxh at eecs.berkeley.edu>; crawl at sdsc.edu <mailto:crawl at sdsc.edu>
> Subject: Re: [kepler-users] Kepler: Array instatiation and Array
> element assignment
>
> Hi Ric,
>
> I'm not sure what you mean by "programmatically."
> What you describe below is a program in an imperative language.
> In Kepler, the primary imperative language is Java. So you
> could write an actor in Java that does this.
>
> There are also hooks to write actors in MATLAB and Python,
> which are also imperative languages.
>
> If instead you are trying to define a workflow that builds
> this variable, then the only director with an imperative
> flavor is the FSM. I think it could be awkward to define
> it in an FSM.
>
> You could use a dataflow director or PN and SequenceToArray
> actor, but these are distinctly not imperative.
>
> In Kepler, parameters are defined as expressions in the
> Ptolemy expression language.
> The expression language is also not an imperative language.
> It is a functional language. So you don't actually specify
> sequences of steps for defining variables.
>
> It occurs to me that it could be very useful to define
> subclass of Parameter, say PythonParameter, that specifies
> a parameter value that is initialized by running a Python
> script... This would probably be fairly easy to write...
> Any interest in this?
>
> Edward
>
>
>
> On 9/30/12 12:39 PM, Ricardo.Pascual at csiro.au
> <mailto:Ricardo.Pascual at csiro.au> wrote:
>
>
> Hi All,
>
> Oooops wrong title.
>
> Thanks,
>
> Ric
>
> ________________________________________
> From: kepler-users-bounces at kepler-project.org
> <mailto:kepler-users-bounces at kepler-project.org>
> [kepler-users-bounces at kepler-project.org
> <mailto:kepler-users-bounces at kepler-project.org>] On Behalf Of
> Ricardo.Pascual at csiro.au <mailto:Ricardo.Pascual at csiro.au>
> [Ricardo.Pascual at csiro.au <mailto:Ricardo.Pascual at csiro.au>]
> Sent: Sunday, 30 September 2012 9:11 PM
> To: Kepler-users at kepler-project.org
> <mailto:Kepler-users at kepler-project.org>; cxh at eecs.berkeley.edu
> <mailto:cxh at eecs.berkeley.edu>; crawl at sdsc.edu <mailto:crawl at sdsc.edu>
> Subject: [ExternalEmail] Re: [kepler-users] netCDF
>
> Hi All,
>
> I am about a week old into Kepler and having difficulty defining an
> array variable programmatically. I have search the internet for
> this to no avail. I know how to do it as a constant by assigning
> the value = {"x1", ...}.
>
> What I like to do is define a variable with scope workflow wide
> say
>
> string fileNames[];
>
> then assign values to it as in
>
> fileNames[0] = "file0"
> fileNames[1] = "file1"
>
>
> and so on.
>
>
> Thank you very much,
>
> Ric
> _______________________________________________
> Kepler-users mailing list
> Kepler-users at kepler-project.org <mailto:Kepler-users at kepler-project.org>
> http://lists.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-users
> _______________________________________________
> Kepler-users mailing list
> Kepler-users at kepler-project.org <mailto:Kepler-users at kepler-project.org>
> http://lists.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-users
>
> <eal.vcf>_______________________________________________
> Kepler-users mailing list
> Kepler-users at kepler-project.org <mailto:Kepler-users at kepler-project.org>
> http://lists.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-users
>
>
>
>
> _______________________________________________
>
> Kepler-users mailing list
>
> Kepler-users at kepler-project.org
> <mailto:Kepler-users at kepler-project.org>
>
> http://lists.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-users
>
>
>
> --
>
> Christopher Brooks, PMP University of California
>
> CHESS Executive Director US Mail: 337 Cory Hall
>
> Programmer/Analyst CHESS/Ptolemy/Trust Berkeley, CA 94720-1774
>
> ph: 510.643.9841 (Office: 545Q Cory)
>
> home: (F-Tu) 707.665.0131 cell: 707.332.0670
>
>
>
> _______________________________________________
> Kepler-users mailing list
> Kepler-users at kepler-project.org
> http://lists.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-users
>
More information about the Kepler-users
mailing list