[aspect-devel] [deal.II] Duplicate Vertices

[Wolfgang Bangerth]

> Initially, I was planning for each writer to put the data points
> passed to it in the filter, then actually write all output at once
> after flush() is called.  If we can put this functionality in
> DataOutBase::write_* then it will simplify things.

Ultimately, I don't care very much where it happens. If you have a good 
idea how to do it go with it.

My gut feeling is that by the time you stick it into the streams, you've 
already ripped the information of what data is defined where into 
separate pieces and you'd have to piece it back together inside the 
stream object. I think it would be simpler to do it inside the write_* 
functions.

An additional advantage is that if you do it in the write_* functions, 
you can still operate on the Patches data structure which is shared 
between all the writers. So, any functionality you write that works on 
the Patches is something you can share between different file format 
writers (you can, even if you don't right away) whereas stuff that you 
write for a particular stream is likely going to be one-off.


> Maybe I don't fully understand this, but it seems like it would have
> problems renumbering the cell nodes and handling multiple data values
> at a single point.  As an example, suppose we have a mesh with cells
> A & B, and points 0, 1, 2, 3:
>
> +--A--+--B--+
 > 0    1,2    3
>
> Then the vector returned by this function would be [0, 1, invalid,
> 2].  However, when you output cell B, it will consist of nodes
> "invalid" and 2, with no way of knowing what "invalid" corresponds
> to.

I thought of it the other way around: if the vector is
   [invalid, invalid, 1, invalid]
then 'invalid' indicates that this is a unique point and the '1' 
represents that point 2 is a non-unique point that should be re-mapped to 1.


>  Also, if we wanted to average multiple values on a point like
> Guido suggested, we would need to know which points are remapped to
> which other points.

I actually don't particularly like the idea of averaging. If fields are 
truly discontinuous, my feeling is that this is how they should be 
output. But this is something one could of course choose in the VtkFlags 
structure or similar and then come up with a generic way to compute this 
from the Patches.


>  The DataOutFilter class would maintain
> structures to hold this remapping information, which would also mean
> we could avoid recomputing this for each of the DataOutBase::write_*
> functions.  It is also possible to hold these structures in
> DataOutBase, but that seems to violate the class abstraction and you
> get in trouble if write_nodes() is called for multiple meshes with a
> given DataOutBase.

If I understand you correctly, then DataOutFilter would be a data 
structure that computes information from the patches and makes it 
available to the write_* functions. It would generalize the data 
computed by the function I had proposed before?

This seems like the right direction to me.


> My impression of a stream is that whatever goes in comes out in the
> same order possibly with some formatting changes.  I wasn't sure if
> maintaining this sort of order was important for the deal.ii output
> but it sounds like the proposed changes in ordering and redundancy
> should be OK.

Yes. The naming may have been unfortunate -- interpret with some latitude.

Best
  W.

-- 
------------------------------------------------------------------------
Wolfgang Bangerth               email:            bangerth at math.tamu.edu
                                 www: http://www.math.tamu.edu/~bangerth/