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

Thu Mar 28 16:38:33 CDT 2019

On Thu, Mar 28, 2019 at 1:38 PM Dave May <dave.mayhem23 at gmail.com> wrote:

> 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??
>

Sure. The C is poop anyway because its writing a quick and dirty format.
The file itself also does not matter because
the format is embarassing. The whole point here is automation. It should
automatically go end-to-end so Matt does
nothing but load the file into Paraview.

   Matt

> 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/>
>>
>

-- 
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/6fd5d8fc/attachment.html>