<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Mar 20, 2015 at 12:08 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"><span class=""><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>
</span> 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>
<span class=""><br>
<br>
maxDims[dim] = dims[dim];<br>
</span><span class=""> chunkDims[dim] = dims[dim];<br>
</span> ++dim;<br>
- if (bs > 1) {<br>
+ if (bs >= 1) {<br>
dims[dim] = bs;<br>
<span class=""> maxDims[dim] = dims[dim];<br>
</span><span class=""> chunkDims[dim] = dims[dim];<br>
}<br>
</span> 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>
<span class=""><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></span></blockquote><div><br></div><div>If we special case here, we must special case in everything we do, such as automatic generation of Xdmf.</div><div>I would rather say that the PETSc format always has the bs in it, which makes it easier to process and</div><div>consistent. However, we allowing reading of of a set without blocksize.</div><div><br></div><div>We would have the ability to write without blocksize by setting the blocksize to -1.</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="">
</span> otherwise I think we should undo Matt's change.<br>
<span class="HOEnZb"><font color="#888888"><br>
Barry<br>
</font></span><div class="HOEnZb"><div class="h5"><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>
</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>