[vtkusers] vtkCellDerivatives
Martin Genet
martin.genet at polytechnique.edu
Thu Jan 28 01:29:40 EST 2016
Of course! Looking forward to see this new notification mechanism in
action… Martin
On 27/01/2016 22:01, Andy Bauer wrote:
> 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
> <mailto: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 <mailto: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
> <mailto: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.
>>
>> 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 <mailto: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
>> <mailto: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
>>> <mailto: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
>>>> <mailto: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.
>>>>>
>>>>> Cheers,
>>>>> Andy
>>>>>
>>>>> On Mon, Dec 28, 2015 at 5:50 PM,
>>>>> Martin Genet
>>>>> <martin.genet at polytechnique.edu
>>>>> <mailto: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
>>>>>> <mailto: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 www.kitware.com
>>>>>> <http://www.kitware.com>
>>>>>>
>>>>>> Visit other Kitware
>>>>>> open-source projects at
>>>>>> 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
>>>>>>
>>>>>> Search the list archives at:
>>>>>> http://markmail.org/search/?q=vtkusers
>>>>>>
>>>>>> Follow this link to
>>>>>> subscribe/unsubscribe:
>>>>>> http://public.kitware.com/mailman/listinfo/vtkusers
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtkusers/attachments/20160128/379b9a0c/attachment-0001.html>
More information about the vtkusers
mailing list