On Sun, Mar 29, 2015 at 4:00 PM, Håkon Strandenes
wrote:
> Den 2015-03-29 21:48, skrev Matthew Knepley:
>
>>
>> But of course there already is a PETSc-specific HDF5 format. Someone
>> made up "/MESH/nodes/x". This is the essence of HDF5,
>> XML, etc. that they are not actually formats, but rather
Den 2015-03-29 21:48, skrev Matthew Knepley:
But of course there already is a PETSc-specific HDF5 format. Someone
made up "/MESH/nodes/x". This is the essence of HDF5,
XML, etc. that they are not actually formats, but rather storage
technologies like the UNIX filesystem. Someone still has to dec
On Sun, Mar 29, 2015 at 2:41 PM, Barry Smith wrote:
>
> > On Mar 29, 2015, at 6:40 AM, Matthew Knepley wrote:
> >
> > On Sat, Mar 28, 2015 at 10:36 PM, Barry Smith
> wrote:
> >
> > > On Mar 28, 2015, at 10:04 PM, Matthew Knepley
> wrote:
> > >
> > > On Sat, Mar 28, 2015 at 9:59 PM, Barry Smith
> On Mar 29, 2015, at 6:40 AM, Matthew Knepley wrote:
>
> On Sat, Mar 28, 2015 at 10:36 PM, Barry Smith wrote:
>
> > On Mar 28, 2015, at 10:04 PM, Matthew Knepley wrote:
> >
> > On Sat, Mar 28, 2015 at 9:59 PM, Barry Smith wrote:
> >
> > Hakon,
> >
> > I have pushed to the branch
> >
Thanks. Unfortuneatly, I am not in my office until april 7th or 8th, and
am not able to test this out until then.
I have also seen the other replies to this post. I might have some ideas
on how to solve this in a bit more flexible way, but again, I cannot
work on this until I am back in office
On Sat, Mar 28, 2015 at 10:36 PM, Barry Smith wrote:
>
> > On Mar 28, 2015, at 10:04 PM, Matthew Knepley wrote:
> >
> > On Sat, Mar 28, 2015 at 9:59 PM, Barry Smith wrote:
> >
> > Hakon,
> >
> > I have pushed to the branch
> barry/feature-hdf5-flexible-initial-dimension and next the chang
> On Mar 28, 2015, at 10:04 PM, Matthew Knepley wrote:
>
> On Sat, Mar 28, 2015 at 9:59 PM, Barry Smith wrote:
>
> Hakon,
>
> I have pushed to the branch barry/feature-hdf5-flexible-initial-dimension
> and next the change so that Vecs and Vecs obtained from
> DMCreateGlobalVector() wi
On Sat, Mar 28, 2015 at 9:59 PM, Barry Smith wrote:
>
> Hakon,
>
> I have pushed to the branch
> barry/feature-hdf5-flexible-initial-dimension and next the change so that
> Vecs and Vecs obtained from DMCreateGlobalVector() with a DMDA will NOT
> have the extra dimension if BS == 1. To add
Hakon,
I have pushed to the branch barry/feature-hdf5-flexible-initial-dimension
and next the change so that Vecs and Vecs obtained from DMCreateGlobalVector()
with a DMDA will NOT have the extra dimension if BS == 1. To add that extra
dimension even when bs == 1 with VecView() or to han
> On Mar 25, 2015, at 10:36 AM, Håkon Strandenes wrote:
>
> Did you come to any conclusion on this issue?
No. Different people think a different default is best for different reasons.
To get the conversation going again I'll propose an approach that allows
both; PetscViewerHDF5SetSomethin
Did you come to any conclusion on this issue?
Regards,
Håkon
On 20. mars 2015 22:02, Håkon Strandenes wrote:
On 20. mars 2015 20:48, Barry Smith wrote:
Why is 1 dimension a special case that is not worthy of its own
format? The same thing would hold for 2d and 3d. One could then argue
that we
On 20. mars 2015 20:48, Barry Smith wrote:
Why is 1 dimension a special case that is not worthy of its own format? The
same thing would hold for 2d and 3d. One could then argue that we should have a
single six dimensional format for the files for all vectors that PETSc
produces. Then a 1d prob
> On Mar 20, 2015, at 1:37 PM, Matthew Knepley wrote:
>
> On Fri, Mar 20, 2015 at 12:32 PM, Barry Smith wrote:
>
> > On Mar 20, 2015, at 1:17 PM, Matthew Knepley wrote:
> >
> > On Fri, Mar 20, 2015 at 12:08 PM, Barry Smith wrote:
> >
> > > On Mar 20, 2015, at 11:31 AM, Håkon Strandenes
> >
On Fri, Mar 20, 2015 at 12:32 PM, Barry Smith wrote:
>
> > On Mar 20, 2015, at 1:17 PM, Matthew Knepley wrote:
> >
> > On Fri, Mar 20, 2015 at 12:08 PM, Barry Smith
> wrote:
> >
> > > On Mar 20, 2015, at 11:31 AM, Håkon Strandenes
> wrote:
> > >
> > > Yes, in the HDF5 file. Currently a dof=1 D
> On Mar 20, 2015, at 1:17 PM, Matthew Knepley wrote:
>
> On Fri, Mar 20, 2015 at 12:08 PM, Barry Smith wrote:
>
> > On Mar 20, 2015, at 11:31 AM, Håkon Strandenes wrote:
> >
> > 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
On Fri, Mar 20, 2015 at 12:08 PM, Barry Smith wrote:
>
> > On Mar 20, 2015, at 11:31 AM, Håkon Strandenes
> wrote:
> >
> > 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.
>
> Actually a 1d
> On Mar 20, 2015, at 11:31 AM, Håkon Strandenes wrote:
>
> 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.
Actually a 1d DMDA is stored as a NX dataset, a 2d DMDA is stored as a NY x
NX
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.
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
Håkon Strandenes writes:
> I mean that if you decide to stick with the current way of
> reading/writing a "plain 1D" Vec with N elements as a N x 1
> array/dataset, you should treat a dof=1 DMDA Vec as an NZ x NY x NX x 1
> array/dataset.
In the HDF5 file? I agree.
signature.asc
Description
On 20. mars 2015 16:15, Jed Brown wrote:
Håkon Strandenes writes:
That formulation is obviously not one of my best. I did not mean that it
was consistent with respect to what is done or not done in Python.
My point was that when using DMDA's in PETSc, you consistently
"disregard" the dof whe
Håkon Strandenes writes:
> That formulation is obviously not one of my best. I did not mean that it
> was consistent with respect to what is done or not done in Python.
>
> My point was that when using DMDA's in PETSc, you consistently
> "disregard" the dof when dof=1, i.e. create 3D arrays ins
That formulation is obviously not one of my best. I did not mean that it
was consistent with respect to what is done or not done in Python.
My point was that when using DMDA's in PETSc, you consistently
"disregard" the dof when dof=1, i.e. create 3D arrays instead of 4D (for
a 3D DMDA). A dump
Håkon Strandenes writes:
> I think this "special treatment" of DMDA Vecs with dof=1 is a consistent
> behaviour.
Why is it more consistent? There are many places in the Python standard
libraries where tuples of size 1 are returned for the analogue of dof=1,
instead of implicitly unwrapping that
In my opinion, one should handle a 1D Vec as a 1D dataset and vice
versa. Why? Because that is the most logical behaviour for the users.
In the code I am working on, I use Python, with h5py, to generate grids,
which is used to create a DMDA, and the initial condition on this DMDA
is again load
> On Mar 19, 2015, at 9:05 PM, Matthew Knepley wrote:
>
> On Thu, Mar 19, 2015 at 8:00 PM, Barry Smith wrote:
>
> MATT READ THIS EMAIL!
>
> Ok here is the scoop. In VecView_MPI_HDF5() is the code (use meta x
> vc-annotate in emacs)
>
> df09a399 src/vec/vec/impls/mpi/pdvec.c (Matthew K
On Thu, Mar 19, 2015 at 8:00 PM, Barry Smith wrote:
>
> MATT READ THIS EMAIL!
>
> Ok here is the scoop. In VecView_MPI_HDF5() is the code (use meta x
> vc-annotate in emacs)
>
> df09a399 src/vec/vec/impls/mpi/pdvec.c (Matthew Knepley 2011-01-20
> 16:27:23 -0600 682) if (bs >= 1) {
>
MATT READ THIS EMAIL!
Ok here is the scoop. In VecView_MPI_HDF5() is the code (use meta x
vc-annotate in emacs)
df09a399 src/vec/vec/impls/mpi/pdvec.c (Matthew Knepley 2011-01-20
16:27:23 -0600 682) if (bs >= 1) {
272345b0 src/vec/vec/impls/mpi/pdvec.c (Karl Rupp2013-
27 matches
Mail list logo
