[Paraview-developers] GUI not updating for OpenFOAM reader in v4.0.1

Utkarsh Ayachit utkarsh.ayachit at kitware.com
Fri Jul 12 23:17:28 EDT 2013


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: FixOpenFOAM.patch
Type: application/octet-stream
Size: 3698 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/paraview-developers/attachments/20130712/e4a28a41/attachment.obj>


More information about the Paraview-developers mailing list