[vtkusers] Fwd: vtkRInterface question

[Wes Turner]

Forwarding the discussion back to the VTK list in case this ends up helping
others.

- Wes

---------- Forwarded message ----------
From: Wes Turner <wes.turner at kitware.com>
Date: Mon, Jan 23, 2012 at 11:19 AM
Subject: Re: vtkRInterface question
To: "Pugmire, Dave" <pugmire at ornl.gov>
Cc: "jeff.baumes at kitware.com" <jeff.baumes at kitware.com>, Berk Geveci <
berk.geveci at kitware.com>


Dave,

I don't normally use the vtkRInterface like this.  In general, I access it
through the wrapper class vtkRCalculatorFilter() and provide the entire
command as a single call.  Can you try a few things for me?  Put all your
REval commands into a single command like:

RI->AssignVTKDataArrayToRVariable(input, "input");
RI->EvalRScript("source('file.q')\nsave.image(file='state.RData')\nresult =
foo(input)\n");

I did not think that state is reliably maintained between the multiple
calls to EvalRScript and it is a good place to start looking.  If this
fails, then try:

RI->AssignVTKDataArrayToRVariable(input, "input");
RI->EvalRScript("source('file.q')\nsave.image(file='state.RData')\ninput");

This invocation will just print out the variable input and will allow you
to determine if the variable is being set correctly.

Alternately, I am including a function we use that uses the
RCalculatorFilter.  note that we set one RScript there much as I am asking
you to do above.

If none of these work, how hard would it be to send your actual code for me
to take a quick look at?  Sending "file.q" would allow me to take a look at
your entire process, but I can always dummy up a definition of "foo()" if
need be.

- Wes


On Fri, Jan 20, 2012 at 11:07 AM, Pugmire, Dave <pugmire at ornl.gov> wrote:

> Hi,
> Tom Otahal referred me to you for questions on the vtkRInterface.
> I'm having a lot of trouble integrating the vtkRInterface into VisIt for a
> particular use case.
> I'm loading in an R script that was created by a statistician, and feeding
> it vtk data arrays for processing.
> The R script defines a function, "foo()", which I then call on the vtk
> data array.
> When I make the call, it crashes. gdb isn't catching the crash either, but
> putting print statements in, it's dying side of the eval call on the
> embedded R API.
>
> Here is the odd thing. If I save the state of the R session to disk, then
> load this file into a stand alone R, the function call will succeed. I also
> added it to the RTesting suite, and it runs fine. So, it's nothing to do w/
> the vtkR component, it must be in what I'm doing.
> Any ideas on this sort of thing?
>
> Here is some code on what I'm doing:
>
>
> vtkRInterface *RI = vtkRInterface::New();
> RI->EvalRScript("source('file.q')\n");
> RI->AssignVTKDataArrayToRVariable("input", input);
> RI->EvalRScript("save.image(file='state.RData')\n");
>
> RI->EvalRscript("result = foo(input)\n");
>
> RI->AssignRVariableToVTKDataArray("result", result);
>
>
> This will fail inside the
> RI->EvalRscript("result = foo(input)\n");
>
>
> However, if I load state.RData into an R session, I can call: result =
> foo(input), and it will succeed.
>
> Thanks for any insight,suggestions you might have.
>
> Dave
>
>
>


-- 
Wesley D. Turner, Ph.D.
Kitware, Inc.
Technical Leader
28 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-881-4920



-- 
Wesley D. Turner, Ph.D.
Kitware, Inc.
Technical Leader
28 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-881-4920
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.vtk.org/pipermail/vtkusers/attachments/20120123/1f55a292/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: voPCAStatistics.h
Type: text/x-chdr
Size: 593 bytes
Desc: not available
URL: <http://www.vtk.org/pipermail/vtkusers/attachments/20120123/1f55a292/attachment.h>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: voPCAStatistics.cpp
Type: text/x-c++src
Size: 10527 bytes
Desc: not available
URL: <http://www.vtk.org/pipermail/vtkusers/attachments/20120123/1f55a292/attachment.cpp>