[Paraview-developers] GUI not updating for OpenFOAM reader in v4.0.1
Paul Edwards
paul.m.edwards at gmail.com
Sat Jul 13 00:47:46 EDT 2013
Thanks for the patch - that works :)
On 13 July 2013 04:17, Utkarsh Ayachit <utkarsh.ayachit at kitware.com> wrote:
> Paul,
>
> Try the attached patch. It's a quick hack prototyping some of the
> design changes in info-property/domain updates that could work in
> general. I need to think/investigate a little more before I am
> comfortable committing these. Let me know if this helps?
>
> Utkarsh
>
> On Fri, Jul 12, 2013 at 1:25 PM, Utkarsh Ayachit
> <utkarsh.ayachit at kitware.com> wrote:
>> Paul,
>>
>> Mind sending me the data? I tried with the motor bike data I have but
>> I cannot reproduce the steps you mentioned.
>>
>> Utkarsh
>>
>> On Fri, Jul 12, 2013 at 12:33 PM, Paul Edwards <paul.m.edwards at gmail.com> wrote:
>>> From looking at the reader it is not just the patches - the cell and
>>> point arrays are also dependent and even the timesteps. Having
>>> filtering logic sounds great but I would like to be able to get
>>> something working quickly and I'd imagine this would take some time.
>>>
>>> Is it a bug that the GUI is not updating when the data from
>>> RequestInformation changes? If so, I could try and fix that otherwise
>>> I'll need to do a custom widget for a short term solution.
>>>
>>> Regards,
>>> Paul
>>>
>>> On 12 July 2013 13:50, Utkarsh Ayachit <utkarsh.ayachit at kitware.com> wrote:
>>>> Hmm, that's actually a problem we run into frequently -- reader panels
>>>> wanting to change some available list when another option is changed.
>>>> Let me think about it some more to see what would be a long term
>>>> supportable solution. In the past, we have done exactly that, write a
>>>> custom panel (which would now translate to writing a custom widget),
>>>> but there are a few problems with this approach:
>>>>
>>>> + if we implement this such that the "CaseType" property will be
>>>> "pushed" immediately after the user changes it in the UI and then
>>>> update the "available patches" list, it goes against how the
>>>> properties panel is supposed to work, no property should be updated
>>>> until the user hits "Apply".
>>>> + If we implement this such that the "available patches" are updated
>>>> after the "Apply" is hit, then the user-experience is bad, the user
>>>> typically expects to setup all properties before hitting apply. Now he
>>>> has to do this always in 2 steps.
>>>>
>>>> Let me take a look at the reader. If the reader can produce all
>>>> avialable "patches" at the start, we can all filtering logic to the
>>>> domains to only show relevant patches based on the state of CaseType.
>>>> What do you think?
>>>>
>>>> Utkarsh
>>>>
>>>>
>>>> On Fri, Jul 12, 2013 at 5:41 AM, Paul Edwards <paul.m.edwards at gmail.com> wrote:
>>>>> Utkarsh,
>>>>>
>>>>> I've looked into this a bit more. The OpenFOAM reader has a
>>>>> vtkDataArraySelection that is used to store the patches. This list is
>>>>> updated in RequestInformation and the list will changed depending on
>>>>> whether the "Case Type" is "Decomposed" or "Reconstructed" (combobox
>>>>> in the GUI). Once decomposed is chosen and apply is clicked it will
>>>>> rerun the RequestInformation and the vtkDataArraySelection will be
>>>>> updated. The difference is that before this would also update the GUI
>>>>> but it is not happening now.
>>>>>
>>>>> Ideally it would be best to make a call to RequestInformation as soon
>>>>> as the "Case Type" is chosen and update the GUI - is there a way to do
>>>>> this from the XML? Alternatively, is there a way to just get it to
>>>>> update after "Apply" is clicked in the XML (as it used to)? The only
>>>>> other solution I can see is to create a custom object panel (where
>>>>> either of the above options wouldn't be too difficult to
>>>>> implement....)
>>>>>
>>>>> What do you think?
>>>>>
>>>>> Thanks,
>>>>> Paul
>>>>>
>>>>> On 11 July 2013 10:17, Paul Edwards <paul.m.edwards at gmail.com> wrote:
>>>>>> Utkarsh,
>>>>>>
>>>>>> Any decomposed OpenFOAM case where the mesh has been generated with
>>>>>> the hex mesher will be able to reproduce this. I have sent you a link
>>>>>> to motorBike example from OpenFOAM which I have decomposed and meshed
>>>>>> in case you do not have any examples to hand. Here are the steps to
>>>>>> reproduce:
>>>>>>
>>>>>> * Open the motorBike.foam in ParaView
>>>>>> * Set "Case Type" to "Decomposed Case"
>>>>>> [ Now you will be able to see 6 items in "Mesh Regions" but these are
>>>>>> not the surfaces on the motorBike ]
>>>>>> * Click "Apply"
>>>>>> [ Previously you would now see all the motorBike surfaces in addition
>>>>>> to the original ones in the "Mesh Regions" ]
>>>>>>
>>>>>> To make all the surfaces appear, go to the Python Shell and type:
>>>>>>
>>>>>> s = GetActiveSource
>>>>>> s.MeshRegions = []
>>>>>>
>>>>>> Thanks,
>>>>>> Paul
>>>>>>
>>>>>> On 10 July 2013 17:51, Utkarsh Ayachit <utkarsh.ayachit at kitware.com> wrote:
>>>>>>> Paul,
>>>>>>>
>>>>>>> How do I try to reproduce this? Do you have a sample dataset?
>>>>>>>
>>>>>>> Utkarsh
>>>>>>>
>>>>>>> On Wed, Jul 10, 2013 at 12:05 PM, Paul Edwards <paul.m.edwards at gmail.com> wrote:
>>>>>>>> Btw the patch list isn't empty - it just used to update once "Apply"
>>>>>>>> had been clicked and now it doesn't (for some reason it doesn't have
>>>>>>>> all the patches until RequestData has been called...). Does anyone
>>>>>>>> have any hints where to look in order to fix this?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Paul
>>>>>>>>
>>>>>>>> On 9 July 2013 18:51, Paul Edwards <paul.m.edwards at gmail.com> wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> In the latest version of ParaView I do not see all the patches for a
>>>>>>>>> decomposed OpenFOAM solution. This used to work in previous versions
>>>>>>>>> although I am not sure why it used to get called - I can't see any
>>>>>>>>> obvious changes to the OpenFOAM reader. Has anything changed with the
>>>>>>>>> way the ArraySelectionDomains work?:
>>>>>>>>>
>>>>>>>>> <StringVectorProperty information_only="1"
>>>>>>>>> name="PatchArrayInfo">
>>>>>>>>> <ArraySelectionInformationHelper attribute_name="Patch" />
>>>>>>>>> </StringVectorProperty>
>>>>>>>>> <StringVectorProperty animateable="0"
>>>>>>>>> command="SetPatchArrayStatus"
>>>>>>>>> element_types="2 0"
>>>>>>>>> information_property="PatchArrayInfo"
>>>>>>>>> name="MeshRegions"
>>>>>>>>> number_of_elements="0"
>>>>>>>>> number_of_elements_per_command="2"
>>>>>>>>> repeat_command="1">
>>>>>>>>> <ArraySelectionDomain name="array_list">
>>>>>>>>> <RequiredProperties>
>>>>>>>>> <Property function="ArrayList"
>>>>>>>>> name="PatchArrayInfo" />
>>>>>>>>> </RequiredProperties>
>>>>>>>>> </ArraySelectionDomain>
>>>>>>>>> </StringVectorProperty>
>>>>>>>>>
>>>>>>>>> A workaround for the moment is to use the python shell - I can see the
>>>>>>>>> properties by doing:
>>>>>>>>>
>>>>>>>>> s = GetActiveSource()
>>>>>>>>> s.GetProperty('PatchArrayInfo')
>>>>>>>>>
>>>>>>>>> And, I can even get the GUI to update with:
>>>>>>>>>
>>>>>>>>> s.MeshRegions = []
>>>>>>>>>
>>>>>>>>> Any ideas how I can fix this?
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Paul
>>>>>>>> _______________________________________________
>>>>>>>> Paraview-developers mailing list
>>>>>>>> Paraview-developers at paraview.org
>>>>>>>> http://public.kitware.com/mailman/listinfo/paraview-developers
More information about the Paraview-developers
mailing list