[petsc-dev] DMDA VTK viewer regression: field names missing

[Dave May]

On Thu, 28 Mar 2019 at 18:05, Matthew Knepley <knepley at gmail.com> wrote:

> On Thu, Mar 28, 2019 at 12:47 PM Dave May via petsc-dev <
> petsc-dev at mcs.anl.gov> wrote:
>
>> I'd advocate flattening everything as a scalar field. Why?
>> 1) the xml vtk formats for vector only work if ncomponents = 3, so for a
>> 2d field you have to insert a dummy set of zero values for the z component
>> 2) its simple to build vector fields which paraview can render if the
>> scalar fields are properly named (and inserting the k-components with
>> zeroes if required)
>> 3) It will work for case 2 and case 3
>>
>
> The painful thing on the other side is that you cannot plot glyphs for the
> vector field without
> defining it by hand with the calculator. This was enough to kick me in the
> ass and define it.
>

So you're fine screwing up your C code and storing unnecessary data in a
file (e.g. the dumm zeros) in 2D to accommodate paraviews broken support
for their own native file format??

I'd say that using the calculator is a small price to pay and I'd prefer to
use it over messing up my code to accommodate problems with others software


>   Matt
>
>
>> On Thu, 28 Mar 2019 at 17:13, Patrick Sanan <patrick.sanan at gmail.com>
>> wrote:
>>
>>>
>>>
>>> Am Do., 28. März 2019 um 09:10 Uhr schrieb Patrick Sanan <
>>> patrick.sanan at gmail.com>:
>>>
>>>> Agreed that
>>>> - these viewers should prioritize being quick and viewable with as
>>>> little post-processing as possible
>>>> - this change is bad in throwing away the field name metadata
>>>>
>>>> The trick here seems to be knowing what the user is representing with a
>>>> multi-dof DMDA, and being faithful to that in the output file. This could be
>>>> 1. a single scalar field
>>>> 2. multiple scalar fields (which the user wants to store interlaced, as
>>>> opposed to using a DMComposite)
>>>> 3. a single vector-valued field
>>>> 4. multiple scalar or vector fields, of arbitrary dimensions (adding up
>>>> the total dof of the DMDA), interlaced
>>>>
>>>> Case 4 can be approximated by case 2, as in Jed's initial example.
>>>> I believe that the PetscSection / PetscField framework was introduced
>>>> to more generally support this, at least for DMPlex.
>>>>
>>> PetscField isn't a thing - I meant the various PetscSection*Field*()
>>> functions.
>>>
>>>>
>>>> My PR broke (or at least harmed) case 2, to allow for more-convenient
>>>> handling of case 3.
>>>> As Jed says, this was motivated by requiring less post-processing to
>>>> view a vector field in Paraview,
>>>> but it created the need for more post-processing for the
>>>> multiple-scalar-field approach.
>>>>
>>>> Options to fix this include
>>>> a. Revert to the old behavior
>>>> b. Provide options to the user to distinguish between cases 2 and 3
>>>> (multiple scalar fields vs vector field)
>>>> c. Try to automatically detect which type of output (say, check if any
>>>> field names have been set)
>>>> d. Investigate supporting case 4 (arbitrary fields of arbitrary
>>>> dimension) by using PetscSection
>>>> e. (If even possible) Properly name the components of a vector in a VTK
>>>> file
>>>>
>>>> Before I start poking around, I'm shaky on assessing options d and e!
>>>>
>>>>
>>>>
>>>>
>>>> Am Do., 28. März 2019 um 08:21 Uhr schrieb Dave May via petsc-dev <
>>>> petsc-dev at mcs.anl.gov>:
>>>>
>>>>>
>>>>>
>>>>> On Thu, 28 Mar 2019 at 15:42, Jed Brown via petsc-dev <
>>>>> petsc-dev at mcs.anl.gov> wrote:
>>>>>
>>>>>> Matthew Knepley <knepley at gmail.com> writes:
>>>>>>
>>>>>> > On Wed, Mar 27, 2019 at 10:56 PM Jed Brown via petsc-dev <
>>>>>> > petsc-dev at mcs.anl.gov> wrote:
>>>>>> >
>>>>>> >> Prior to this PR, which was merged for 3.10
>>>>>> >>
>>>>>> >>
>>>>>> >>
>>>>>> https://bitbucket.org/petsc/petsc/pull-requests/1029/dmda-vtk-viewing-output-multiple-dof/diff
>>>>>> >>   https://bitbucket.org/petsc/petsc/commits/ea2d7708fa6
>>>>>> >>
>>>>>> >> we could have files that look like the following, and thus were
>>>>>> easy to
>>>>>> >> navigate in Paraview and Visit.
>>>>>> >>
>>>>>> >
>>>>>> > Tell me if I am wrong (since I do not run it this way). I think the
>>>>>> point
>>>>>> > of Patrick's change is a good one, and
>>>>>> > necessary to view things with DMStag.
>>>>>>
>>>>>> Or maybe just necessary to avoid needing to use multiple files or add
>>>>>> filters.
>>>>>>
>>>>>> > What Jed dislikes, rightly, is that some metadata has gone missing.
>>>>>> > Does Xdmf allow you to name the components? The way I do this
>>>>>> > petsc_gen_xdmf.py is to write the whole thing as Patrick does, but
>>>>>> > then create views into the data using the component names. It sound
>>>>>> > like this should be doable here.
>>>>>>
>>>>>> Perhaps.  A key reason for using VTK viewers is that they're
>>>>>> relatively
>>>>>> quick and foolproof compared to formats that need libraries and/or
>>>>>> auxiliary files.
>>>>>
>>>>>
>>>>> I completely agree with the above comment. I consider these files as
>>>>> "instant and usable viz".
>>>>>
>>>>> I'd like both the dm field names and the vec name to be used to define
>>>>> the vtk field names.
>>>>>
>>>>> One idea:
>>>>>   vecname_fieldname
>>>>> falling back to
>>>>>   "field"%d_fieldname, where %d is the index of the vector to be
>>>>> written (we can determine this as all vectors are cached to support
>>>>> appended data)
>>>>> faillng back to
>>>>>   "field"%d_%d
>>>>> where the last index here is the block index.
>>>>>
>>>>> These names should work with unnamed dm fields, multiple vectors
>>>>> obtained from DMCreateGlobalVector or VecDuplicate. It does not account
>>>>> immediately address what happens if two vectors produce identical fieldname
>>>>> - code should be added for that using the last fall back. I think this
>>>>> would be better than using the stringifed memory address which was used
>>>>> before Patrick's PR. That suffered from the same issue Jed raised at the
>>>>> start of this thread (users must remember the order vecs were written)
>>>>>
>>>>> Thanks
>>>>> Dave
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>
>
> --
> What most experimenters take for granted before they begin their
> experiments is infinitely more interesting than any results to which their
> experiments lead.
> -- Norbert Wiener
>
> https://www.cse.buffalo.edu/~knepley/
> <http://www.cse.buffalo.edu/~knepley/>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20190328/1f6c1422/attachment-0001.html>