<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi Jean,<br>
<br>
PV is not liking this dataset!<br>
<br>
I reproduce the crash, a std::bad_alloc exception that occurs in
vtkDataSetSurfaceFilter::NewFastGeomQuad(int). This filter is
choking on the data, not sure why. <br>
<br>
I tried it on a Cray and PV used about 32 G just to open one scalar
array!<br>
<br>
I see a bunch of rendering artifacts that usually are a result of
coincident geometry and go away when I zoom in. I notice that the
data is much larger in x and y than z.<br>
Perhaps it's a rendering precision issue? Not sure if the surface
filter could suffer from a precision issue. Any one out there know
precision related caveats?<br>
<br>
Do you have overlapping/coincident geometry? Maybe ghost cells? It
looked like you did. You may want to try to remove these, it may
help. I couldn't find any other obvious bugs in your dataset.<br>
<br>
Burlen<br>
<br>
<br>
rocky:/work/ParaView/ParaView-4.1.0-Linux-64bit/lib/paraview-4.1$LD_LIBRARY_PATH=`pwd`:$LD_LIBRARY_PATH
./pvserver --enable-bt<br>
Waiting for client...<br>
Connection URL: cs://rocky.dhcp:11111<br>
Accepting connection(s): rocky.dhcp:11111<br>
Client connected.<br>
terminate called after throwing an instance of 'std::bad_alloc'<br>
what(): std::bad_alloc<br>
<br>
=========================================================<br>
Process id 15417 Caught SIGABRT<br>
Program Stack:<br>
WARNING: The stack trace will not use advanced capabilities because
this is a release build.<br>
0x3769a0ef90 : ??? [(???) ???:-1]<br>
0x37696359e9 : gsignal [(libc.so.6) ???:-1]<br>
0x37696370f8 : abort [(libc.so.6) ???:-1]<br>
0x376c660565 : __gnu_cxx::__verbose_terminate_handler()
[(libstdc++.so.6) ???:-1]<br>
0x376c65e6c6 : ??? [(???) ???:-1]<br>
0x376c65e6f3 : ??? [(???) ???:-1]<br>
0x376c65e91f : ??? [(???) ???:-1]<br>
0x376c65ee2d : operator new(unsigned long) [(libstdc++.so.6) ???:-1]<br>
0x376c65eec9 : operator new[](unsigned long) [(libstdc++.so.6)
???:-1]<br>
0x7fc327d46712 : vtkDataSetSurfaceFilter::NewFastGeomQuad(int)
[(libvtkFiltersGeometry-pv4.1.so.1) ???:-1]<br>
0x7fc327d46aca : vtkDataSetSurfaceFilter::InsertTriInHash(long long,
long long, long long, long long, long long)
[(libvtkFiltersGeometry-pv4.1.so.1) ???:-1]<br>
0x7fc327d4b5c0 :
vtkDataSetSurfaceFilter::UnstructuredGridExecute(vtkDataSet*,
vtkPolyData*, int) [(libvtkFiltersGeometry-pv4.1.so.1) ???:-1]<br>
0x7fc3212874a6 :
vtkPVGeometryFilter::UnstructuredGridExecute(vtkUnstructuredGridBase*,
vtkPolyData*, int) [(libvtkPVVTKExtensionsRendering-pv4.1.so.1)
???:-1]<br>
0x7fc321287cf9 : vtkPVGeometryFilter::RequestData(vtkInformation*,
vtkInformationVector**, vtkInformationVector*)
[(libvtkPVVTKExtensionsRendering-pv4.1.so.1) ???:-1]<br>
0x7fc3265ca744 : vtkExecutive::CallAlgorithm(vtkInformation*, int,
vtkInformationVector**, vtkInformationVector*)
[(libvtkCommonExecutionModel-pv4.1.so.1) ???:-1]<br>
0x7fc3265c6c5c :
vtkDemandDrivenPipeline::ExecuteData(vtkInformation*,
vtkInformationVector**, vtkInformationVector*)
[(libvtkCommonExecutionModel-pv4.1.so.1) ???:-1]<br>
0x7fc3265c56a1 :
vtkCompositeDataPipeline::ExecuteData(vtkInformation*,
vtkInformationVector**, vtkInformationVector*)
[(libvtkCommonExecutionModel-pv4.1.so.1) ???:-1]<br>
0x7fc3265c9613 :
vtkDemandDrivenPipeline::ProcessRequest(vtkInformation*,
vtkInformationVector**, vtkInformationVector*)
[(libvtkCommonExecutionModel-pv4.1.so.1) ???:-1]<br>
0x7fc3265e1a59 :
vtkStreamingDemandDrivenPipeline::ProcessRequest(vtkInformation*,
vtkInformationVector**, vtkInformationVector*)
[(libvtkCommonExecutionModel-pv4.1.so.1) ???:-1]<br>
0x7fc3265c3737 :
vtkCompositeDataPipeline::ForwardUpstream(vtkInformation*)
[(libvtkCommonExecutionModel-pv4.1.so.1) ???:-1]<br>
0x7fc3265c95bc :
vtkDemandDrivenPipeline::ProcessRequest(vtkInformation*,
vtkInformationVector**, vtkInformationVector*)
[(libvtkCommonExecutionModel-pv4.1.so.1) ???:-1]<br>
0x7fc3265e1a59 :
vtkStreamingDemandDrivenPipeline::ProcessRequest(vtkInformation*,
vtkInformationVector**, vtkInformationVector*)
[(libvtkCommonExecutionModel-pv4.1.so.1) ???:-1]<br>
0x7fc3265c3737 :
vtkCompositeDataPipeline::ForwardUpstream(vtkInformation*)
[(libvtkCommonExecutionModel-pv4.1.so.1) ???:-1]<br>
0x7fc3265c95bc :
vtkDemandDrivenPipeline::ProcessRequest(vtkInformation*,
vtkInformationVector**, vtkInformationVector*)
[(libvtkCommonExecutionModel-pv4.1.so.1) ???:-1]<br>
0x7fc3265e1a59 :
vtkStreamingDemandDrivenPipeline::ProcessRequest(vtkInformation*,
vtkInformationVector**, vtkInformationVector*)
[(libvtkCommonExecutionModel-pv4.1.so.1) ???:-1]<br>
0x7fc3265c8b6e : vtkDemandDrivenPipeline::UpdateData(int)
[(libvtkCommonExecutionModel-pv4.1.so.1) ???:-1]<br>
0x7fc3265e36c5 : vtkStreamingDemandDrivenPipeline::Update(int)
[(libvtkCommonExecutionModel-pv4.1.so.1) ???:-1]<br>
0x7fc32256db2a :
vtkGeometryRepresentation::RequestData(vtkInformation*,
vtkInformationVector**, vtkInformationVector*)
[(libvtkPVClientServerCoreRendering-pv4.1.so.1) ???:-1]<br>
0x7fc3265ca744 : vtkExecutive::CallAlgorithm(vtkInformation*, int,
vtkInformationVector**, vtkInformationVector*)
[(libvtkCommonExecutionModel-pv4.1.so.1) ???:-1]<br>
0x7fc3265c6c5c :
vtkDemandDrivenPipeline::ExecuteData(vtkInformation*,
vtkInformationVector**, vtkInformationVector*)
[(libvtkCommonExecutionModel-pv4.1.so.1) ???:-1]<br>
0x7fc3265c56a1 :
vtkCompositeDataPipeline::ExecuteData(vtkInformation*,
vtkInformationVector**, vtkInformationVector*)
[(libvtkCommonExecutionModel-pv4.1.so.1) ???:-1]<br>
0x7fc3265c9613 :
vtkDemandDrivenPipeline::ProcessRequest(vtkInformation*,
vtkInformationVector**, vtkInformationVector*)
[(libvtkCommonExecutionModel-pv4.1.so.1) ???:-1]<br>
0x7fc3265e1a59 :
vtkStreamingDemandDrivenPipeline::ProcessRequest(vtkInformation*,
vtkInformationVector**, vtkInformationVector*)
[(libvtkCommonExecutionModel-pv4.1.so.1) ???:-1]<br>
0x7fc3265c8b6e : vtkDemandDrivenPipeline::UpdateData(int)
[(libvtkCommonExecutionModel-pv4.1.so.1) ???:-1]<br>
0x7fc3265e36c5 : vtkStreamingDemandDrivenPipeline::Update(int)
[(libvtkCommonExecutionModel-pv4.1.so.1) ???:-1]<br>
0x7fc322581c8f :
vtkPVDataRepresentation::ProcessViewRequest(vtkInformationRequestKey*,
vtkInformation*, vtkInformation*)
[(libvtkPVClientServerCoreRendering-pv4.1.so.1) ???:-1]<br>
0x7fc32256d699 :
vtkGeometryRepresentation::ProcessViewRequest(vtkInformationRequestKey*,
vtkInformation*, vtkInformation*)
[(libvtkPVClientServerCoreRendering-pv4.1.so.1) ???:-1]<br>
0x7fc32256f781 :
vtkGeometryRepresentationWithFaces::ProcessViewRequest(vtkInformationRequestKey*,
vtkInformation*, vtkInformation*)
[(libvtkPVClientServerCoreRendering-pv4.1.so.1) ???:-1]<br>
0x7fc3225a5508 :
vtkPVView::CallProcessViewRequest(vtkInformationRequestKey*,
vtkInformation*, vtkInformationVector*)
[(libvtkPVClientServerCoreRendering-pv4.1.so.1) ???:-1]<br>
0x7fc3225a56d2 : vtkPVView::Update()
[(libvtkPVClientServerCoreRendering-pv4.1.so.1) ???:-1]<br>
0x7fc3225964fa : vtkPVRenderView::Update()
[(libvtkPVClientServerCoreRendering-pv4.1.so.1) ???:-1]<br>
0x7fc3225959b1 : vtkPVRenderView::ResetCamera()
[(libvtkPVClientServerCoreRendering-pv4.1.so.1) ???:-1]<br>
0x7fc329b5770f : vtkPVRenderViewCommand(vtkClientServerInterpreter*,
vtkObjectBase*, char const*, vtkClientServerStream const&,
vtkClientServerStream&, void*)
[(libvtkPVServerManagerApplication-pv4.1.so.1) ???:-1]<br>
0x7fc3271ed250 :
vtkClientServerInterpreter::CallCommandFunction(char const*,
vtkObjectBase*, char const*, vtkClientServerStream const&,
vtkClientServerStream&) [(libvtkClientServer-pv4.1.so.1) ???:-1]<br>
0x7fc3271f2183 :
vtkClientServerInterpreter::ProcessCommandInvoke(vtkClientServerStream
const&, int) [(libvtkClientServer-pv4.1.so.1) ???:-1]<br>
0x7fc3271f0ef2 :
vtkClientServerInterpreter::ProcessOneMessage(vtkClientServerStream
const&, int) [(libvtkClientServer-pv4.1.so.1) ???:-1]<br>
0x7fc3271f13ad :
vtkClientServerInterpreter::ProcessStream(vtkClientServerStream
const&) [(libvtkClientServer-pv4.1.so.1) ???:-1]<br>
0x7fc328e98854 :
vtkSIProperty::ProcessMessage(vtkClientServerStream&)
[(libvtkPVServerImplementationCore-pv4.1.so.1) ???:-1]<br>
0x7fc328e988fe : vtkSIProperty::Push(paraview_protobuf::Message*,
int) [(libvtkPVServerImplementationCore-pv4.1.so.1) ???:-1]<br>
0x7fc328e99550 : vtkSIProxy::Push(paraview_protobuf::Message*)
[(libvtkPVServerImplementationCore-pv4.1.so.1) ???:-1]<br>
0x7fc328e7e32a :
vtkPVSessionCore::PushStateInternal(paraview_protobuf::Message*)
[(libvtkPVServerImplementationCore-pv4.1.so.1) ???:-1]<br>
0x7fc328e7b3a4 :
vtkPVSessionCore::PushState(paraview_protobuf::Message*)
[(libvtkPVServerImplementationCore-pv4.1.so.1) ???:-1]<br>
0x7fc328e79fad :
vtkPVSessionBase::PushState(paraview_protobuf::Message*)
[(libvtkPVServerImplementationCore-pv4.1.so.1) ???:-1]<br>
0x7fc328e866dc : vtkPVSessionServer::OnClientServerMessageRMI(void*,
int) [(libvtkPVServerImplementationCore-pv4.1.so.1) ???:-1]<br>
0x7fc326a2c163 : vtkMultiProcessController::ProcessRMI(int, void*,
int, int) [(libvtkParallelCore-pv4.1.so.1) ???:-1]<br>
0x7fc326a2c37b : vtkMultiProcessController::ProcessRMIs(int, int)
[(libvtkParallelCore-pv4.1.so.1) ???:-1]<br>
0x7fc328cf7b46 :
vtkTCPNetworkAccessManager::ProcessEventsInternal(unsigned long,
bool) [(libvtkPVClientServerCoreCore-pv4.1.so.1) ???:-1]<br>
0x4019a6 : __gxx_personality_v0 [(pvserver) ???:-1]<br>
0x4019ee : main [(pvserver) ???:-1]<br>
0x3769621b45 : __libc_start_main [(libc.so.6) ???:-1]<br>
0x4016aa : __gxx_personality_v0 [(pvserver) ???:-1]<br>
=========================================================<br>
<br>
<br>
<br>
<div class="moz-cite-prefix">On 06/19/2014 03:05 PM, jean mensa
wrote:<br>
</div>
<blockquote
cite="mid:CAKtPhBJtVg4UUcNLe8sy0r_fr20ERm_FEBM3YZgkLTQ4YV3b7A@mail.gmail.com"
type="cite">
<div dir="ltr">I am running the 4.0.1, I will upgrade to 4.1. In
the meantime it follows the dataset (~1GB).
<div><a moz-do-not-send="true"
href="https://drive.google.com/file/d/0B2rIXNfrsOf8M054bzFNSmo3UU0/edit?usp=sharing">https://drive.google.com/file/d/0B2rIXNfrsOf8M054bzFNSmo3UU0/edit?usp=sharing</a><br>
<div>Thanks for helping,</div>
<div>j</div>
</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Thu, Jun 19, 2014 at 5:42 PM, Burlen
Loring <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:bloring@lbl.gov" target="_blank">bloring@lbl.gov</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"> Could you share the
dataset? Maybe I can reproduce the issue.<br>
<br>
Which version of PV are you using? You're not using the
latest(4.1) if --enable-bt isn't there. Upgrading to 4.1
may help...
<div>
<div class="h5"><br>
<br>
<div>On 06/19/2014 02:10 PM, jean mensa wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">The server has about 16GB of ram,
while the client has 8GB. I am loading only one
array and I am starting the server with a simple
'pvserver' then I establish the connection
manually from PV which I start simply calling
'paraview'.
<div> <br>
</div>
<div><span
style="font-family:arial,sans-serif;font-size:13px">--enable-bt
is not a valid option but dmesg does show a
segfault: </span><font face="arial,
sans-serif">at-spi-bus-laun[17239]: segfault
at 968 ip 0000003e4e425321 sp 00007fff9770a040
error 4 in libX11.so.6.3.0</font></div>
<div><font face="arial, sans-serif">I don't think
that this can be the problem though because
the same excessive memory load happens on the
client mac with no crash and a different
version of X (XQuartz).</font></div>
<div><span
style="font-family:arial,sans-serif;font-size:13px"><br>
</span></div>
<div><span
style="font-family:arial,sans-serif;font-size:13px">in
the case of remote rendering I should see a
black window coming from pvserver where the
dataset should be displayed, right? well I see
the window but nothing gets rendered on it...
if remote rendering is disabled do I still see
the window?</span></div>
<div><font face="arial, sans-serif">j</font></div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Thu, Jun 19, 2014 at
4:43 PM, Burlen Loring <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:burlen.loring@gmail.com"
target="_blank">burlen.loring@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0
0 0 .8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
questions:<br>
So how much ram is on this system?<br>
How many arrays are you loading? If memory
is an issue you may get by by loading only
one (or fewer) of them.<br>
What command line are you using to start the
server?<br>
<br>
Can you start the client and server with
--enable-bt on the respective command lines?
This should print a stack trace during the
crash. If it does send it to the list. If PV
is killed because its out of memory this may
have been logged (on linux: dmesg | egrep -i
'killed process').<br>
<br>
about your original question: When in client
server(not multicore) with the server
running on a remote system and the client on
your desktop, the client only has to display
images rendered on the server. so very low
load on the client side. If you're seeing a
high load in that case , remote rendering is
probably disabled, perhaps this is a bug.<br>
<br>
multicore would disable remote rendering ,
according to a recent post on the mail list.<br>
<br>
mulitcore the client and servers run on the
same system and thus the X server load could
in fact be coming from the server rather
than the client.
<div>
<div><br>
<br>
<div>On 06/19/2014 01:26 PM, jean mensa
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">it's the crash. The
server loads about 8GB of data and
then it idles. The status bar also
shows that
the vtkUnstructuredGridReader is
loading the dataset and it reaches
100% without giving any errors. The
problem seems to be displaying the
data...
<div> <br>
<br>
On Thu, Jun 19, 2014 at 4:17 PM,
Burlen Loring <<a
moz-do-not-send="true"
href="mailto:bloring@lbl.gov"
target="_blank">bloring@lbl.gov</a>>
wrote:<br>
><br>
> The server seems to load the
dataset properly but no image is
shown on the client.<br>
><br>
> OK, so is this the crash or a
new issue? If there's no image how
could you tell the server loaded
the dataset correctly?<br>
><br>
><br>
><br>
> On 06/19/2014 12:53 PM, jean
mensa wrote:<br>
><br>
> same result. I disabled
multicore and I was already using
0MB remote rendering threshold. I
have tried with paraview on both
linux and macosx. The server seems
to load the dataset properly but
no image is shown on the client.<br>
><br>
><br>
><br>
> On Thu, Jun 19, 2014 at 3:40
PM, Burlen Loring <<a
moz-do-not-send="true"
href="mailto:bloring@lbl.gov"
target="_blank">bloring@lbl.gov</a>>
wrote:<br>
>><br>
>> Ug. you're using the
multicore option to start the
servers! I believe that this
forces remote rendering off. That
would explain your issues. Could
you try duisabling the multi core
option and start your servers
manually?<br>
>><br>
>><br>
>> On 06/19/2014 12:29 PM,
Burlen Loring wrote:<br>
>><br>
>> OK, one possibility is
that it may be related to remote
rendering settings. Under menu
Edit->Settings->Render
View->Server there is a remote
render threshold. I always set
this to 0 bytes to ensure remote
parallel rendering. What's yours
set to?<br>
>><br>
>> On 06/19/2014 12:18 PM,
jean mensa wrote:<br>
>><br>
>> Sorry, I didn't explain
it properly. I have already tried
to connect to a pvserver from a
GUI running on the client (without
an ssh connection then) but it
also drains the memory on Xorg.
What is the load supposed to be on
a client-pvserver connection?<br>
>> Thanks,<br>
>><br>
>><br>
>> On Thu, Jun 19, 2014 at
3:08 PM, Burlen Loring <<a
moz-do-not-send="true"
href="mailto:bloring@lbl.gov"
target="_blank">bloring@lbl.gov</a>>
wrote:<br>
>>><br>
>>> Jean,<br>
>>><br>
>>> What you describe is
expected. X forwarding doesn't
work well for visualizing large
datasets. The point is : don't use
X forwarding. The links show how
to configure the client server
connection without X forwarding.
Make sure that there is no -X on
the ssh command line.<br>
>>><br>
>>> Burlen<br>
>>><br>
>>><br>
>>> On 06/19/2014 11:46
AM, jean mensa wrote:<br>
>>><br>
>>> When I do that Xorg
process on the client drains the
memory up until it crashes. The
connection I think is properly
established since it works fine
for smaller datasets. What should
the load on the client be in that
case?<br>
>>> j<br>
>>><br>
>>><br>
>>> On Thu, Jun 19, 2014
at 2:14 PM, Burlen Loring <<a
moz-do-not-send="true"
href="mailto:bloring@lbl.gov"
target="_blank">bloring@lbl.gov</a>>
wrote:<br>
>>>><br>
>>>> Yes, this is
expected. The OpenGL calls get
piped to your local system. This
includes data like vertices and
colors as well. X forwarding
doesn't give good performance and
with large data it may not even be
feasible.<br>
>>>><br>
>>>> You need to set
up client server connection.<br>
>>>><br>
>>>> <a
moz-do-not-send="true"
href="http://www.paraview.org/Wiki/Reverse_connection_and_port_forwarding"
target="_blank">http://www.paraview.org/Wiki/Reverse_connection_and_port_forwarding</a><br>
>>>> <a
moz-do-not-send="true"
href="http://www.paraview.org/Wiki/ParaView:Server_Configuration"
target="_blank">http://www.paraview.org/Wiki/ParaView:Server_Configuration</a><br>
>>>> <a
moz-do-not-send="true"
href="http://www.paraview.org/Wiki/Setting_up_a_ParaView_Server"
target="_blank">http://www.paraview.org/Wiki/Setting_up_a_ParaView_Server</a><br>
>>>> <a
moz-do-not-send="true"
href="http://www.paraview.org/Wiki/ParaView_And_Mesa_3D"
target="_blank">http://www.paraview.org/Wiki/ParaView_And_Mesa_3D</a><br>
>>>><br>
>>>><br>
>>>><br>
>>>><br>
>>>> On 06/19/2014
10:33 AM, jean mensa wrote:<br>
>>>><br>
>>>> Hi all,<br>
>>>> I have a rather
large unstructured pvtu dataset
(about 4 million points) which I
am visualizing on a remote server.
I am running the paraview GUI
(with the multicore option) on the
server and I connect to it via ssh
sharing the X server. In this way
I can control the GUI running on
the serve. I thought that with
this configuration I would only
receive a screenshot of the window
and no actual data from paraview
but the client seems to share at
least some of the load of the
visualization. Is this the
expected behaviour? How can I
avoid loading data on the client
side?<br>
>>>> Thanks in
advance,<br>
>>>><br>
>>>> --<br>
>>>> Jean A. Mensa<br>
>>>> Graduate
Assistant<br>
>>>> University of
Miami<br>
>>>> RSMAS - MPO<br>
>>>> 4600 Rickenbacker
Causeway<br>
>>>> Miami, FL
33149-1098<br>
>>>><br>
>>>><br>
>>>>
_______________________________________________<br>
>>>> Powered by <a
moz-do-not-send="true"
href="http://www.kitware.com"
target="_blank">www.kitware.com</a><br>
>>>><br>
>>>> Visit other
Kitware open-source projects at <a
moz-do-not-send="true"
href="http://www.kitware.com/opensource/opensource.html"
target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
>>>><br>
>>>> Please keep
messages on-topic and check the
ParaView Wiki at: <a
moz-do-not-send="true"
href="http://paraview.org/Wiki/ParaView"
target="_blank">http://paraview.org/Wiki/ParaView</a><br>
>>>><br>
>>>> Follow this link
to subscribe/unsubscribe:<br>
>>>> <a
moz-do-not-send="true"
href="http://public.kitware.com/mailman/listinfo/paraview"
target="_blank">http://public.kitware.com/mailman/listinfo/paraview</a><br>
>>>><br>
>>>><br>
>>><br>
>>><br>
>>><br>
>>> --<br>
>>> Jean A. Mensa<br>
>>> Graduate Assistant<br>
>>> University of Miami<br>
>>> RSMAS - MPO<br>
>>> 4600 Rickenbacker
Causeway<br>
>>> Miami, FL 33149-1098<br>
>>><br>
>>><br>
>><br>
>><br>
>><br>
>> --<br>
>> Jean A. Mensa<br>
>> Graduate Assistant<br>
>> University of Miami<br>
>> RSMAS - MPO<br>
>> 4600 Rickenbacker
Causeway<br>
>> Miami, FL 33149-1098<br>
>><br>
>><br>
>><br>
><br>
><br>
><br>
> --<br>
> Jean A. Mensa<br>
> Graduate Assistant<br>
> University of Miami<br>
> RSMAS - MPO<br>
> 4600 Rickenbacker Causeway<br>
> Miami, FL 33149-1098<br>
><br>
><br>
<br>
<br>
<br>
--<br>
Jean A. Mensa<br>
Graduate Assistant<br>
University of Miami<br>
RSMAS - MPO<br>
4600 Rickenbacker Causeway<br>
Miami, FL 33149-1098</div>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
Powered by <a moz-do-not-send="true" href="http://www.kitware.com" target="_blank">www.kitware.com</a>
Visit other Kitware open-source projects at <a moz-do-not-send="true" href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/opensource/opensource.html</a>
Please keep messages on-topic and check the ParaView Wiki at: <a moz-do-not-send="true" href="http://paraview.org/Wiki/ParaView" target="_blank">http://paraview.org/Wiki/ParaView</a>
Follow this link to subscribe/unsubscribe:
<a moz-do-not-send="true" href="http://public.kitware.com/mailman/listinfo/paraview" target="_blank">http://public.kitware.com/mailman/listinfo/paraview</a>
</pre>
</blockquote>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
<div dir="ltr"><b>Jean A. Mensa</b>
<div><i>Graduate Assistant</i><br>
</div>
<div>
<div>University of Miami<br>
</div>
<div>
<div>RSMAS - MPO</div>
<div>4600 Rickenbacker Causeway</div>
<div>Miami, FL 33149-1098<br>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
<div dir="ltr"><b>Jean A. Mensa</b>
<div><i>Graduate Assistant</i><br>
</div>
<div>
<div>University of Miami<br>
</div>
<div>
<div>RSMAS - MPO</div>
<div>4600 Rickenbacker Causeway</div>
<div>Miami, FL 33149-1098<br>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<br>
</body>
</html>