[vtkusers] vtkCellDerivatives
Andy Bauer
andy.bauer at kitware.com
Wed Jan 27 16:01:33 EST 2016
Hi Martin,
We're working on some infrastructure to document API changes. I'd like to
wait to merge your changes for switching the tensor order output for
vtkCellDerivatives until that's done. That way it will be easier to notify
everyone of this change (even though it's not technically changing the API,
just how the output should be interpreted). We're hoping it will be ready
in a week. Is that ok to wait for merging your changes into VTK master?
Thanks,
Andy
On Fri, Jan 22, 2016 at 2:42 PM, Andy Bauer <andy.bauer at kitware.com> wrote:
> Hi Martin,
>
> In case you didn't receive the email notice, your changes have been merged
> into master. Thanks for your contribution to VTK! This looks like it was
> your first contribution. I hope it wasn't too onerous to get done but the
> community works hard to make sure that the code is high quality and well
> tested.
>
> Best regards,
> Andy
>
> On Fri, Jan 22, 2016 at 10:22 AM, Andy Bauer <andy.bauer at kitware.com>
> wrote:
>
>> It looks like vtkCellDerivates is the only class that uses vtkTensor.
>> When we switch vtkCellDerivatives to C ordering I think we'll just remove
>> vtkTensor. Less code with the same functionality and probably better
>> efficiency -- tough to beat that :)
>>
>> On Fri, Jan 22, 2016 at 9:03 AM, Martin Genet <
>> martin.genet at polytechnique.edu> wrote:
>>
>>> Sounds good.
>>>
>>> However, here the culprit seems to be vtkTensor, which stores the data
>>> in column. vtkCellDerivatives simply fills a vtkTensor (filling is storage
>>> independent, since one provides the actual components), and then returns
>>> the underlying vector.
>>>
>>> One option would be to make vtkCellDerivatives independent of vtkTensor.
>>>
>>> But I think it would be better to correct the storage in vtkTensor.
>>> Actually, it seems that vtkTensor is used only in vtkCellDerivatives, so it
>>> would not change the rest of the library.
>>>
>>> Let me know what you would prefer.
>>>
>>> Martin
>>>
>>>
>>> On 20/01/2016 19:19, Andy Bauer wrote:
>>>
>>> I've looked at this a bit more along with others and unfortunately
>>> there's some inconsistency in VTK for tensor ordering. If you look at the
>>> vtkCell::Derivatives() documentation (
>>> http://www.vtk.org/doc/nightly/html/classvtkCell.html#aff3d8332e9d7d556a9d2e9f91173d068),
>>> it's using a C/row-major ordering. There's some places in that have done
>>> row-major and others that have done column major. For the most part it
>>> hasn't been an issue since many/most of the uses of tensor have been
>>> symmetric but it should be fixed regardless.
>>>
>>> I've entered a mantis issue for this at
>>> <http://www.paraview.org/Bug/view.php?id=15949>
>>> http://www.paraview.org/Bug/view.php?id=15949.
>>>
>>> Would you be willing to go in and make the change to vtkCellDerivatives?
>>> I'm hoping to go through your changes to that class sometime today.
>>>
>>> On Wed, Jan 20, 2016 at 7:52 AM, Andy Bauer <andy.bauer at kitware.com>
>>> wrote:
>>>
>>>> Hmm, in fact it does. I was looking at vtkGradientFilter instead of
>>>> vtkCellDerivatives for the ordering of the output of the gradient of a
>>>> vector. I think the output order is supposed to be fortran/column-major
>>>> ordering like vtkCellDerivatives instead of C/row-major ordering like
>>>> vtkGradientFilter. Well, you can see the confusion that crops up and maybe
>>>> that's why vtkTensors was done that way. In any case, let me verify for
>>>> sure which way is correct and get back to you on this.
>>>>
>>>> On Wed, Jan 20, 2016 at 5:24 AM, Martin Genet <
>>>> <martin.genet at polytechnique.edu>martin.genet at polytechnique.edu> wrote:
>>>>
>>>>> Thanks Andy.
>>>>>
>>>>> Well, I might be wrong but I'm under the impression that
>>>>> vtkCellDerivatives returns [du/dx, dv/dx, dw/dx, du/dy, dv/dy, ...]. Am I
>>>>> wrong?
>>>>>
>>>>> Martin
>>>>>
>>>>>
>>>>> On 20/01/2016 03:07, Andy Bauer wrote:
>>>>>
>>>>> Hi Martin,
>>>>>
>>>>> I haven't looked closely enough at vtkTensors (I don't know if I even
>>>>> knew about it before today) but indeed the ordering output in
>>>>> vtkCellDerivatives for a velocity vector {u,v,w} needs to be [du/dx, du/dy,
>>>>> du/dz, dv/dx, dv/dy, ...] like you have it. I'm not sure when vtkTensors is
>>>>> ordered the way it is.
>>>>>
>>>>> Cheers,
>>>>> Andy
>>>>>
>>>>> On Tue, Jan 19, 2016 at 5:02 PM, Martin Genet <
>>>>> <martin.genet at polytechnique.edu>martin.genet at polytechnique.edu> wrote:
>>>>>
>>>>>> Thanks Andy.
>>>>>>
>>>>>> I need to clarify something: the Derivatives function of vtkCell
>>>>>> objects returns a derivs vector containing the components of the gradient
>>>>>> of some vector field defined at the cell nodes; the components are ordered
>>>>>> in row (as usually in C, i.e., (0,0), (0,1), (0,2), (1,0), (1,1), (1,2),
>>>>>> (2,0), (2,1), (2,2)). Now in the CellDerivatives filter the derivs vector
>>>>>> is used to fill a vtkTensors, and then the filter returns the internal
>>>>>> vector storing the data of the vtkTensors. However, the components of the
>>>>>> vtkTensors are ordered in column (as usually in fortran, i.e., (0,0),
>>>>>> (1,0), (2,0), (0,1), (1,1), (2,1), (0,2), (1,2), (2,2)). Is it on purpose
>>>>>> that the vtkTensors store their data in column and not in row? Isn't it a
>>>>>> little dangerous to mix both storage in the code? Thanks for the
>>>>>> clarification!
>>>>>>
>>>>>> Martin
>>>>>>
>>>>>>
>>>>>> On 18/01/2016 13:32, Andy Bauer wrote:
>>>>>>
>>>>>> Hi Martin,
>>>>>>
>>>>>> Thanks for following up on this. I found the merge request now and
>>>>>> will look at this. In general, developers should request others to do a
>>>>>> code review on this. This can be done via something like "@acbauer please
>>>>>> review this" or sending an email on this VTK list with a link to the merge
>>>>>> request.
>>>>>>
>>>>>> Best,
>>>>>> Andy
>>>>>>
>>>>>> On Mon, Jan 18, 2016 at 6:23 AM, Martin Genet <
>>>>>> <martin.genet at polytechnique.edu>martin.genet at polytechnique.edu>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi Andy,
>>>>>>>
>>>>>>> I followed the directions, and submitted a patch (19 days ago), but
>>>>>>> haven't heard anything back.
>>>>>>>
>>>>>>> In GitLab the merge requests counter is at 0, but when I try to
>>>>>>> create a new merge request from my commit, it tells the merge request
>>>>>>> already exists. Is it being reviewed somewhere? Thanks!
>>>>>>>
>>>>>>> Martin
>>>>>>>
>>>>>>>
>>>>>>> On 29/12/2015 13:22, Andy Bauer wrote:
>>>>>>>
>>>>>>> Hi Martin,
>>>>>>>
>>>>>>> This patch makes sense. It would need a test if you want to get your
>>>>>>> changes into VTK. The directions for contributing to VTK are at
>>>>>>> <https://gitlab.kitware.com/vtk/vtk/blob/master/Documentation/dev/git/develop.md>
>>>>>>> https://gitlab.kitware.com/vtk/vtk/blob/master/Documentation/dev/git/develop.md
>>>>>>> .
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Andy
>>>>>>>
>>>>>>> On Mon, Dec 28, 2015 at 5:50 PM, Martin Genet <
>>>>>>> <martin.genet at polytechnique.edu>martin.genet at polytechnique.edu>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Thanks Andy.
>>>>>>>>
>>>>>>>> What about simply adding another mode, e.g.
>>>>>>>> SetTensorModeToComputeGreenLagrangeStrain, to the vtkCellDerivatives
>>>>>>>> filter? Would the attached patch make sense?
>>>>>>>>
>>>>>>>> Martin
>>>>>>>>
>>>>>>>> On 28/12/2015 14:12, Andy Bauer wrote:
>>>>>>>>
>>>>>>>> Hi Martin,
>>>>>>>>
>>>>>>>> Changing the name of the SetTensorModeToComputeStrain method to
>>>>>>>> something else would break backward compatibility which is generally
>>>>>>>> avoided in VTK. Other options for this include deriving a class to compute
>>>>>>>> non-linear strain from vtkCellDerivatives if it shares enough of the
>>>>>>>> algorithm with the linearized version or maybe just creating a new filter.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Andy
>>>>>>>>
>>>>>>>> On Sat, Dec 26, 2015 at 4:36 PM, Martin Genet <
>>>>>>>> <martin.genet at polytechnique.edu>martin.genet at polytechnique.edu>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Dear VTK users:
>>>>>>>>>
>>>>>>>>> I realize that the vtkCellDerivatives filter, when
>>>>>>>>> SetTensorModeToComputeStrain is activated, returns the symmetric part of
>>>>>>>>> the gradient of the input vector field, which is the linearized strain
>>>>>>>>> tensor, i.e., not a proper measure of deformation when large displacements
>>>>>>>>> are involved. Would that make sense to have two different modes,
>>>>>>>>> SetTensorModeToComputeLinearizedStrain or
>>>>>>>>> SetTensorModeToComputeSymmetricGradient, and SetTensorModeToComputeStrain
>>>>>>>>> or SetTensorModeToComputeGreenLagrangeStrain? Thanks!
>>>>>>>>>
>>>>>>>>> Martin
>>>>>>>>> _______________________________________________
>>>>>>>>> Powered by <http://www.kitware.com>www.kitware.com
>>>>>>>>>
>>>>>>>>> Visit other Kitware open-source projects at
>>>>>>>>> <http://www.kitware.com/opensource/opensource.html>
>>>>>>>>> http://www.kitware.com/opensource/opensource.html
>>>>>>>>>
>>>>>>>>> Please keep messages on-topic and check the VTK FAQ at:
>>>>>>>>> <http://www.vtk.org/Wiki/VTK_FAQ>http://www.vtk.org/Wiki/VTK_FAQ
>>>>>>>>>
>>>>>>>>> Search the list archives at:
>>>>>>>>> <http://markmail.org/search/?q=vtkusers>
>>>>>>>>> http://markmail.org/search/?q=vtkusers
>>>>>>>>>
>>>>>>>>> Follow this link to subscribe/unsubscribe:
>>>>>>>>> <http://public.kitware.com/mailman/listinfo/vtkusers>
>>>>>>>>> http://public.kitware.com/mailman/listinfo/vtkusers
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtkusers/attachments/20160127/d1ef8d9f/attachment.html>
More information about the vtkusers
mailing list