<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Mar 20, 2015 at 12:32 PM, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
> On Mar 20, 2015, at 1:17 PM, Matthew Knepley <<a href="mailto:knepley@gmail.com">knepley@gmail.com</a>> wrote:<br>
><br>
> On Fri, Mar 20, 2015 at 12:08 PM, Barry Smith <<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>> wrote:<br>
><br>
> > On Mar 20, 2015, at 11:31 AM, Håkon Strandenes <<a href="mailto:haakon@hakostra.net">haakon@hakostra.net</a>> wrote:<br>
> ><br>
> > Yes, in the HDF5 file. Currently a dof=1 DMDA Vec is saved as a NZ x NY x NX dataset, wile a dof > 1 is saved as NZ x NY x NX x dof in the HDF5 file.<br>
><br>
> Actually a 1d DMDA is stored as a NX dataset, a 2d DMDA is stored as a NY x NX data set and a 3d DMDA is stored as a NZ x NY x NX data set and an extra dimension is added if dof > 1. And I think this is great and intuitively obvious for users.<br>
><br>
> I agree with Hakon and advocate NOT sticking the extra dimension in when bs is 1. Here is Matt's entire commit<br>
><br>
><br>
> maxDims[dim] = dims[dim];<br>
> chunkDims[dim] = dims[dim];<br>
> ++dim;<br>
> - if (bs > 1) {<br>
> + if (bs >= 1) {<br>
> dims[dim] = bs;<br>
> maxDims[dim] = dims[dim];<br>
> chunkDims[dim] = dims[dim];<br>
> }<br>
> count[dim] = PetscHDF5IntCast(xin->map->n)/bs;<br>
> ++dim;<br>
> - if (bs > 1) {<br>
> + if (bs >= 1) {<br>
> count[dim] = bs;<br>
> ++dim;<br>
> }<br>
> }<br>
> offset[dim] = PetscHDF5IntCast(low/bs);<br>
> ++dim;<br>
> - if (bs > 1) {<br>
> + if (bs >= 1) {<br>
> offset[dim] = 0;<br>
> ++dim;<br>
> }<br>
><br>
> (Then there is Karl's one line fix for reading HDF5 files.)<br>
><br>
> Arguing that handling bs = 1 as a special case greatly (or even modestly) increases the complexity of the PETSc source code is nonsense.<br>
><br>
> So I want a stronger case presented then<br>
><br>
> >> My rationale was to simplify our code path, and have one way to handle fields with components. I did not<br>
> >> want to special case a field with one component.<br>
><br>
> If we special case here, we must special case in everything we do, such as automatic generation of Xdmf.<br>
> I would rather say that the PETSc format always has the bs in it, which makes it easier to process and<br>
> consistent.<br>
<br>
</div></div> From what I see the "easier" is just trivially easier; having a tiny bit more complicated code that is intuitively clear for users seems a better choice.<br>
<span class=""><br>
> However, we allowing reading of of a set without block size.<br>
<br>
</span> Hmm, according to the bug report which I confirmed, VecLoad() refuses to load in a 1d dataset<br></blockquote><div><br></div><div>Yes, I was saying this is the part we change.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="">><br>
> We would have the ability to write without blocksize by setting the blocksize to -1.<br>
<br>
</span> Ok, so now you are still supporting that "special case" but with some totally non-intuitive value for a block size that will crash if used with the vector in any other usage of the vector. How is this either simpler code or more intuitive code.<br></blockquote><div><br></div><div>I am supporting a special case in this function for output, but not for our accepted format. I want</div><div>to avoid a special case in the format, not in the function itself. Then I can use the format from</div><div>other tools without making them complicated too.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
As Hakon notes also, VecView from a DMDA is handled differently with regard to the bs dimension then VecView from a simple "vector". Which is terrible.</blockquote><div><br></div><div>Yes, I think we should change it so that all vectors come with the blocksize.</div><div><br></div><div> Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="HOEnZb"><font color="#888888"><br>
Barry<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
><br>
> Matt<br>
><br>
> otherwise I think we should undo Matt's change.<br>
><br>
> Barry<br>
><br>
><br>
><br>
> ><br>
> > In my humble opinion, it is best to leave the DMDA's as it is, and fix up the code related to the plain Vecs. That code is already full of "if (bs >= 1) dim++" etc. which is useless (as Barry points out).<br>
> ><br>
> > My final point is that one should handle this in a CONSISTENT manner for both "plain Vecs" and "DMDA Vecs", i.e. decide wither one want to always add one dimension for bs and dof or leave that dimension out for the special case with bs=1/dof=1.<br>
> ><br>
> > Håkon<br>
> ><br>
> ><br>
> > On 20. mars 2015 16:57, Jed Brown wrote:<br>
> >> Håkon Strandenes <<a href="mailto:haakon@hakostra.net">haakon@hakostra.net</a>> writes:<br>
> >>> I mean that if you decide to stick with the current way of<br>
> >>> reading/writing a "plain 1D" Vec with N elements as a N x 1<br>
> >>> array/dataset, you should treat a dof=1 DMDA Vec as an NZ x NY x NX x 1<br>
> >>> array/dataset.<br>
> >><br>
> >> In the HDF5 file? I agree.<br>
> >><br>
><br>
><br>
><br>
><br>
> --<br>
> What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>
> -- Norbert Wiener<br>
<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>-- Norbert Wiener</div>
</div></div>