No subject
Tue Jul 9 10:50:44 EDT 2013
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