[Paraview-developers] SOADataArray Templates and Catalyst fail to work

Andy Bauer andy.bauer at kitware.com
Mon Sep 12 16:35:29 EDT 2016


Hi Max,

I'm able to replicate some issues with Live and using the SOA data array.
I've added an issue on Gitlab (
https://gitlab.kitware.com/paraview/paraview/issues/16887). This may be
slightly different than your bug but the fix for the issue may fix the bug
you reported as well.

Thanks,
Andy

On Thu, Sep 8, 2016 at 6:57 AM, Staufer, Max <Max.Staufer at rolls-royce.com>
wrote:

> Just to illustrate,
>
>
>
> Blow is a really small Simulation of a flow in a cavity.
>
>
>
> Left Render window shows Velocity_X component of the SOADataArray made up
> from U V W scalar arrays, right shows U (Velocity_X component) set in
> catalyst as scalar float array.
>
> It’s a two processor run. The Processor0 values look fine while the
> processor1 values don’t.
>
>
>
>
>
> *From:* Paraview-developers [mailto:paraview-developers-
> bounces at paraview.org] *On Behalf Of *Staufer, Max
> *Sent:* Donnerstag, 8. September 2016 09:47
> *To:* Andy Bauer; David Lonie
> *Cc:* paraview-developers at paraview.org
> *Subject:* [CAUTION - EXTERNAL SENDER]: Re: [Paraview-developers]
> SOADataArray Templates and Catalyst fail to work
>
>
>
> Hi Andy,
>
>
>
>   correct, simulation side is the catalyst instrumented code, client side
> is the Paraview GUI for live processing.
>
> I have to admit, that I did not look into the Paraview part yet, but the
> fact that all scalar arrays aka. “standard” float arrays,
>
> one and multiple components, are displayed correctly, when ordered
> correctly in C ordering, but the SOAArray is only displayed correctly
>
> for the first processor, tells me that there is probably something wrong
> on the client, receiving end.
>
>
>
> On that front, what is the role of maxid in a multiprocessor scenario ?
>
>
>
> Max
>
>
>
> *From:* Andy Bauer [mailto:andy.bauer at kitware.com <andy.bauer at kitware.com>]
>
> *Sent:* Mittwoch, 7. September 2016 21:04
> *To:* David Lonie
> *Cc:* Staufer, Max; paraview-developers at paraview.org
> *Subject:* Re: [Paraview-developers] SOADataArray Templates and Catalyst
> fail to work
>
>
>
> Hi Max,
>
> I'm a bit confused as to what you mean by server side and client side for
> this. Are you connecting your Catalyst instrumented simulation with the
> ParaView GUI through the Live functionality?
>
> Cheers,
>
> Andy
>
>
>
> On Wed, Sep 7, 2016 at 11:39 AM, David Lonie <david.lonie at kitware.com>
> wrote:
>
> On Wed, Sep 7, 2016 at 11:16 AM, Staufer, Max
> <Max.Staufer at rolls-royce.com> wrote:
> >   I think I messed up my example, the one below is the correct one,
> sorry about that.
> > Using the SetNumberOfTuples method, actually leads to a direct crash,
> and did not find any reason
> > why it should be necessary, because on the simulation side the pointers
> are correctly pointing to the data.
>
> I suspect there may be an issue because you're redeclaring the 'field'
> identifier inside the 'if (!field)' branch. Most compilers will handle
> such cases as expected, but it's worth trying to change the name of
> the variable for the new array in case the compiler is getting
> confused -- e.g, it may be resolving the SetNumberOfTuples call to the
> wrong 'field' pointer. SetNumberOfTuples should always be safe to call
> on a valid array, so the crash is suspicious.
>
> Either SetNumberOfTuples or SetArray with updateMaxId=true is
> required, because otherwise the dataarray is unaware of how many valid
> elements the buffer contains and will assume 0.
>
> > Only on the Client side there is a problem.
> > I left the MaxId update to the default, the question here would be, what
> value should it be.
> > If I turn it on, the Maxid of the SOADataArray rises to 3*size of the
> component array + 1, which is sort of what I would expect.
> > Is that the correct value?
>
> The expected value of the MaxId variable is ((numComps * numTuples) -
> 1). I'm not sure how you'd get ((numComps * numTuples) + 1).
>
> You can either call SetNumberOfComponents + SetNumberOfTuples to set
> MaxId, or SetNumberOfComponents and SetArray with updateMaxId = true.
> Either way will give the same result in this case. I'd advise using
> SetArray in this case simply to avoid unnecessary memory allocations
> (SetNumberOfTuples triggers a memory allocation for the array data,
> which will be immediately released when SetArray is called).
>
> > Secondly, by updating the Maxid, I got the data transfer correct for the
> first processor but not for the other ones.
> >
> > Any thoughts
>
> I'd try using a different variable identifier than 'field' for the
> array created in the branch. There seems to be something fishy going
> on there with this compiler. Also use updateMaxId = true in this case.
>
> If there's some sort of MPI (or similar) data transfer happening after
> this, there may be an issue there. I'm not terribly familiar with
> Catalyst, so someone else might need to take a look if this doesn't
> resolve your problem.
>
> HTH,
> Dave
>
>
> > -----------------
> > extern "C" void addvectorfieldsoa_(float* vector0,float* vector1,float*
> vector2, char* name) {
> >
> >    vtkCPInputDataDescription* idd = vtkCPPythonAdaptorAPI::
> GetCoProcessorData()->GetInputDescriptionByName("input");
> >
> >      vtkUnstructuredGrid* VTKgrid = vtkUnstructuredGrid::
> SafeDownCast(idd->GetGrid());
> >
> >      if (!VTKgrid) {
> >        vtkGenericWarningMacro("No adaptor grid to attach field data
> to.");
> >        return;
> >      }
> >
> >      if (idd->IsFieldNeeded(name)) {
> >        vtkSOADataArrayTemplate<float>* field =
> >              vtkSOADataArrayTemplate<float>::SafeDownCast(VTKgrid->
> GetCellData()->GetArray(name));
> >
> >        if (!field) {
> >          // vector array
> >          vtkSOADataArrayTemplate<float>* field =
> vtkSOADataArrayTemplate<float>::New();
> >          field->SetNumberOfComponents(3);
> >        //field->SetNumberOfTuples(VTKgrid->GetNumberOfCells());
> >          field->SetName(name);
> >          field->SetArray(0, vector0, VTKgrid->GetNumberOfCells(), false,
> true);
> >          field->SetArray(1, vector1, VTKgrid->GetNumberOfCells(), false,
> true);
> >          field->SetArray(2, vector2, VTKgrid->GetNumberOfCells(), false,
> true);
> >          VTKgrid->GetCellData()->AddArray(field);
> >          field->Delete();
> >        }
> >        else {
> >          field->SetArray(0, vector0, VTKgrid->GetNumberOfCells(), false,
> true);
> >          field->SetArray(1, vector1, VTKgrid->GetNumberOfCells(), false,
> true);
> >          field->SetArray(2, vector2, VTKgrid->GetNumberOfCells(), false,
> true);
> >        }
> >      }
> > }
> >
> > -----Original Message-----
> > From: David Lonie [mailto:david.lonie at kitware.com]
> > Sent: Mittwoch, 7. September 2016 15:38
> > To: Staufer, Max
> > Cc: paraview-developers at paraview.org
> > Subject: Re: [Paraview-developers] SOADataArray Templates and Catalyst
> fail to work
> >
> > Hi Max,
> >
> > I'm having some trouble following your example code:
> >
> > On Wed, Sep 7, 2016 at 4:13 AM, Staufer, Max <
> Max.Staufer at rolls-royce.com> wrote:
> >> However, pushing vector data to the client does not () , the pointer
> >> in the SOA -> AOS Structure works fine on the coprocessor side, but the
> Paraview client displays only random garbage.
> >>
> >> // Add a vector field to the VTK data container using
> >> SOADataArrayTemplate extern "C" void addvectorfieldsoa_(float*
> vector0,float* vector1,float* vector2, char* name) {
> >>    vtkCPInputDataDescription* idd =
> >> vtkCPPythonAdaptorAPI::GetCoProcessorData()->GetInputDescriptionByName
> >> ("input");
> >>
> >>      vtkUnstructuredGrid* VTKgrid =
> >> vtkUnstructuredGrid::SafeDownCast(idd->GetGrid());
> >>
> >>      if (!VTKgrid) {
> >>        vtkGenericWarningMacro("No adaptor grid to attach field data
> to.");
> >>        return;
> >>      }
> >>
> >>      if (idd->IsFieldNeeded(name)) {
> >>        //vtkSOADataArrayTemplate<float>* field =
> //vtkSOADataArrayTemplate<float>::SafeDownCast(VTKgrid->
> GetCellData()->GetArray(name));
> >>        vtkFloatArray* field = vtkFloatArray::SafeDownCast(
> >>          VTKgrid->GetCellData()->GetArray(name));
> >>        if (!field) {
> >>
> >>          // vector array
> >>          vtkSOADataArrayTemplate<float>* field =
> vtkSOADataArrayTemplate<float>::New();
> >>          field->SetNumberOfComponents(3); //field->SetNumberOfTuples(
> VTKgrid->GetNumberOfCells());
> >>          field->SetName(name);
> >>          field->SetArray(vector0, 3*VTKgrid->GetNumberOfCells(), 1);
> >
> > There is no method in vtkSOADataArrayTemplate that matches the signature
> of the above call (in this scope, 'field' is a
> vtkSOADataArrayTemplate<float>).
> >
> >>          field->SetArray(0, vector0, VTKgrid->GetNumberOfCells(),
> false, true);
> >>          field->SetArray(1, vector1, VTKgrid->GetNumberOfCells(),
> false, true);
> >>          field->SetArray(2, vector2, VTKgrid->GetNumberOfCells(),
> false, true);
> >>          VTKgrid->GetCellData()->AddArray(field);
> >>          field->Delete();
> >>        }
> >>        else {
> >>          field->SetArray(0, vector0, VTKgrid->GetNumberOfCells(),
> false, true);
> >>          field->SetArray(1, vector1, VTKgrid->GetNumberOfCells(),
> false, true);
> >>          field->SetArray(2, vector2, VTKgrid->GetNumberOfCells(),
> >> false, true);
> >
> > There is no method in vtkFloatArray that matches the above signature (in
> this scope, 'field' is a vtkFloatArray).
> >
> >>        }
> >>      }
> >> }
> >
> > Is this the actual code? I'd be surprised if it compiles. I suspect that
> if the compiler is allowing the above, it's getting confused about the
> shadowed 'field' variable and doing Very Bad Things instead of throwing an
> error. Does renaming the new array to an unused identifier help anything?
> >
> > Otherwise, I'd try iterating through the data in the raw pointers and
> the data in the data array and print out the values. That might provide
> some clues as to what's going wrong.
> >
> > Also, I see that you've commented out SetNumberOfTuples, and also pass
> 'false' as the updateMaxId argument to SetArray. The array will think that
> it's empty in this situation, which is probably not what you want.
> >
> > HTH,
> > Dave
> > Rolls-Royce Deutschland Ltd & Co KG Sitz/Registered Office:
> Blankenfelde-Mahlow, Deutschland, Registergericht/Court of Register:
> Amtsgericht Potsdam, HRA 2731 P, Persönlich haftende
> Gesellschafterin/General Partner: Rolls-Royce General Partner Limited,
> Sitz/Registered Office: Derby, United Kingdom, Register: Registry of
> Companies Wales and England, 4066556, Directors/Geschäftsführer: Paul
> O’Neil, Alastair McIntosh, Nicole Fehr, Dr. Holger Cartsburg
> Confidentiality Notice: This email and any attachments are confidential to
> the intended recipient and may also be privileged. If you are not the
> intended recipient please delete it from your system and notify the sender.
> You should not copy it or use it for any purpose nor disclose or distribute
> its contents to any other person.
> > The data contained in, or attached to, this e-mail, may contain
> confidential information. If you have received it in error you should
> notify the sender immediately by reply e-mail, delete the message from your
> system and contact +44 (0) 3301235850 (Security Operations Centre) if you
> need assistance. Please do not copy it for any purpose, or disclose its
> contents to any other person.
> >
> > An e-mail response to this address may be subject to interception or
> monitoring for operational reasons or for lawful business practices.
> >
> > (c) 2016 Rolls-Royce plc
> >
> > Registered office: 62 Buckingham Gate, London SW1E 6AT Company number:
> 1003142. Registered in England.
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/
> opensource/opensource.html
>
> Search the list archives at: http://markmail.org/search/?q=
> Paraview-developers
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/paraview-developers
>
>
>
> Rolls-Royce Deutschland Ltd & Co KG Sitz/Registered Office:
> Blankenfelde-Mahlow, Deutschland, Registergericht/Court of Register:
> Amtsgericht Potsdam, HRA 2731 P, Persönlich haftende
> Gesellschafterin/General Partner: Rolls-Royce General Partner Limited,
> Sitz/Registered Office: Derby, United Kingdom, Register: Registry of
> Companies Wales and England, 4066556, Directors/Geschäftsführer: Paul
> O’Neil, Alastair McIntosh, Nicole Fehr, Dr. Holger Cartsburg
> Confidentiality Notice: This email and any attachments are confidential to
> the intended recipient and may also be privileged. If you are not the
> intended recipient please delete it from your system and notify the sender.
> You should not copy it or use it for any purpose nor disclose or distribute
> its contents to any other person.
>
>
> The data contained in, or attached to, this e-mail, may contain
> confidential information. If you have received it in error you should
> notify the sender immediately by reply e-mail, delete the message from your
> system and contact +44 (0) 3301235850 (Security Operations Centre) if you
> need assistance. Please do not copy it for any purpose, or disclose its
> contents to any other person.
>
> An e-mail response to this address may be subject to interception or
> monitoring for operational reasons or for lawful business practices.
>
> (c) 2016 Rolls-Royce plc
>
> Registered office: 62 Buckingham Gate, London SW1E 6AT Company number:
> 1003142. Registered in England.
> Rolls-Royce Deutschland Ltd & Co KG Sitz/Registered Office:
> Blankenfelde-Mahlow, Deutschland, Registergericht/Court of Register:
> Amtsgericht Potsdam, HRA 2731 P, Persönlich haftende
> Gesellschafterin/General Partner: Rolls-Royce General Partner Limited,
> Sitz/Registered Office: Derby, United Kingdom, Register: Registry of
> Companies Wales and England, 4066556, Directors/Geschäftsführer: Paul
> O’Neil, Alastair McIntosh, Nicole Fehr, Dr. Holger Cartsburg
> Confidentiality Notice: This email and any attachments are confidential to
> the intended recipient and may also be privileged. If you are not the
> intended recipient please delete it from your system and notify the sender.
> You should not copy it or use it for any purpose nor disclose or distribute
> its contents to any other person.
>
>
> The data contained in, or attached to, this e-mail, may contain
> confidential information. If you have received it in error you should
> notify the sender immediately by reply e-mail, delete the message from your
> system and contact +44 (0) 3301235850 (Security Operations Centre) if you
> need assistance. Please do not copy it for any purpose, or disclose its
> contents to any other person.
>
> An e-mail response to this address may be subject to interception or
> monitoring for operational reasons or for lawful business practices.
>
> (c) 2016 Rolls-Royce plc
>
> Registered office: 62 Buckingham Gate, London SW1E 6AT Company number:
> 1003142. Registered in England.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/paraview-developers/attachments/20160912/02be1666/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 157712 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/paraview-developers/attachments/20160912/02be1666/attachment-0001.png>


More information about the Paraview-developers mailing list