Re: [petsc-dev] Master broken after changes to PetscSection headers

[Václav Hapla via petsc-dev]

19. září 2019 12:23:43 SELČ, Matthew Knepley  napsal:
>On Thu, Sep 19, 2019 at 6:21 AM Matthew Knepley 
>wrote:
>
>> On Thu, Sep 19, 2019 at 6:20 AM Stefano Zampini
>
>> wrote:
>>
>>> So why it is in the vec package?
>>>
>>
>> Its in IS, so if anything it should go in petscis.h. I will move it
>there.
>>
>
>Now that we are doing this. I think petscsf.h belongs there too, not
>just
>the types.

The is directory just groups different utility classes dealing with integer 
mappings. Probably just from historical reasons. I don't think they should be 
considered belonging to the IS package. I don't see a point in including it all 
in petscis.h. Why e.g. users of KSP should implicitly include all this stuff 
when they don't need it.

Related issue
https://gitlab.com/petsc/petsc/issues/290

Vaclav

>
>   Matt
>
>
>>Matt
>>
>>
>>> Il Gio 19 Set 2019, 13:17 Matthew Knepley  ha
>scritto:
>>>
 I made a new MR. DMLabel uses Section, whereas nothing else in Vec
>does.

Matt

 On Thu, Sep 19, 2019 at 6:03 AM Stefano Zampini <
 stefano.zamp...@gmail.com> wrote:

> Petscsection is part of the vec package. It belongs to petscvec.h
>
> Il Gio 19 Set 2019, 12:50 Hapla Vaclav 
>ha
> scritto:
>
>>
>>
>> On 19 Sep 2019, at 11:25, Matthew Knepley via petsc-dev <
>> petsc-dev@mcs.anl.gov> wrote:
>>
>> I pushed the fix to the branch. Can we remerge it?
>>
>>
>> I think best way would be to create another MR.
>>
>> You should also add
>>   #include 
>> to petscdmlabel.h.
>> This which will also satisfy Lisandro's point.
>>
>> Vaclav
>>
>>
>> Also, I do not understand why tests did not catch this. Its
>obvious
>> what happened. I added that header
>> to convert.c instead of convest.c.
>>
>>Matt
>>
>> On Thu, Sep 19, 2019 at 5:19 AM Stefano Zampini via petsc-dev <
>> petsc-dev@mcs.anl.gov> wrote:
>>
>>> How come this was not caught by the tests? I think we have tests
>with
>>> -Werror
>>>
>>> Il Gio 19 Set 2019, 12:15 Lisandro Dalcin via petsc-dev <
>>> petsc-dev@mcs.anl.gov> ha scritto:
>>>
 The warnings below are from a C build. A C++ build fails right
>away.

 We need to `#include ` somewhere in the public
 headers, at least such that  `#include ` in user code
>works.

 $ git grep petscsection include/
 include/petsc/private/sectionimpl.h:#include 
 include/petscis.h:#include 
 include/petscsection.h:#include 


 /home/devel/petsc/dev/src/snes/utils/convest.c: In function
 ‘PetscConvEstGetConvRate’:
 /home/devel/petsc/dev/src/snes/utils/convest.c:293:14: warning:
 implicit declaration of function ‘PetscSectionGetField’; did
>you mean
 ‘PetscSectionVecView’? [-Wimplicit-function-declaration]
   293 |   ierr = PetscSectionGetField(s, f,
>);CHKERRQ(ierr);
   |  ^~~~
   |  PetscSectionVecView
 /home/devel/petsc/dev/src/snes/utils/convest.c:294:14: warning:
 implicit declaration of function
>‘PetscSectionGetConstrainedStorageSize’
 [-Wimplicit-function-declaration]
   294 |   ierr = PetscSectionGetConstrainedStorageSize(fs,
 );CHKERRQ(ierr);
   |  ^

 --
 Lisandro Dalcin
 
 Research Scientist
 Extreme Computing Research Center (ECRC)
 King Abdullah University of Science and Technology (KAUST)
 http://ecrc.kaust.edu.sa/

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

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

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

Re: [petsc-dev] PETSC_HAVE_ZLIB gone with PR #1853

[Václav Hapla via petsc-dev]

Ok, I agree it would be more systematic to detect whether the file uses 
compression and whether hdf5 is built with zlib. I will look at it soonish. 
Right now I will raise an issue.

Barry, it's not such a big deal for me. It's just that viewer is now untested 
which is a bit risky with respect to potential regressions.

Thanks,
Vaclav


5. září 2019 18:16:59 SELČ, Jed Brown  napsal:
>Can we query HDF5 to determine whether it supports zlib?  When shipping
>shared libraries, some people will use a different libhdf5, so it'd be
>better to determine this at run-time.
>
>"Smith, Barry F. via petsc-dev"  writes:
>
>>Vaclav,
>>
>>  At the time of the PR Jed complained about all the configure
>information passed to PETSc source that was not used or relevant to
>PETSc. 
>>
>>  Hence I did a cleanup, part of the cleanup was packages not
>directly used by PETSc no longer had information generated about them,
>zlib was
>> one of them because I did a grep of HAVE_ZLIB in PETSc which would
>not detect the zlib in the requires. 
>>
>>   We can certainly bring it back ASAP.
>>
>>   But I'd like to explore additional options, since the use of
>zlib in the requires: location is a bit of a hack that only works for
>those specific tests. 
>> You say that HDF fails when trying to process compressed HDF5 if HDF5
>was built without zlib. Is there any other way to determine if the HDF5
>file is compressed with zlib? An HDF5 call specifically or that? Some
>indicate in the file? If so our viewers could use this to check the
>file and generate a very useful error message instead of having HDF5
>misbehave when called.
>>
>>   When bringing it back I will make it more specific, for example
>HDF5_BUILT_WITH_ZLIB because just because zlib exists it doesn't mean
>HDF5 was built with it.
>>
>>   Sorry for the inconvenience, we'll fix it better than ever
>>
>> Barry
>>
>>
>>
>>
>>> On Sep 5, 2019, at 8:52 AM, Hapla Vaclav 
>wrote:
>>> 
>>> Barry, you did a petscconf.h cleanup in BitBucket PR #1834 (merge
>commit 52556f0f).
>>> 
>>> The problem is PETSC_HAVE_ZLIB is no longer set when ZLIB is
>installed.
>>> That effectively disables my tests with `requires: zlib` in
>>>  src/mat/examples/tutorials/ex10.c
>>>  src/ksp/ksp/examples/tutorials/ex27.c
>>> 
>>> That condition is there because loading an HDF5 file which uses
>compression without zlib installed leads to HDF5 errors (very cryptic
>at least in some older HDF5 versions).
>>> 
>>> Was the PETSC_HAVE_ZLIB removal intentional? Could it be brought
>back?
>>> 
>>> Vaclav

Re: [petsc-dev] Negative blocksize

[Václav Hapla via petsc-dev]

Exactly.

Thanks,
Vaclav

4. září 2019 20:15:42 SELČ, "Smith, Barry F."  napsal:
>
>It seems reasonable at SetUp time to make it 1. If we need to have the
>information that user never set it (I don't know why we would want
>this) then that can go into a new flag.
>
>   Barry
>
>
>> On Sep 4, 2019, at 11:15 AM, Matthew Knepley via petsc-dev
> wrote:
>> 
>> On Wed, Sep 4, 2019 at 12:14 PM Václav Hapla via petsc-dev
> wrote:
>> Is there any reason why PetscLayoutSetUp couldn't guarantee blocksize
>>= 1? I don't like the negative value being there forever requiring all
>that PetscAbs business. It seems to me it just complicates things
>unnecessarily.
>> 
>> We are using -1 to indicate "never set", but I don't see any reason
>to keep it after SetUp().
>> 
>>Matt
>>  
>> Thanks,
>> Vaclav
>> 
>> 
>> -- 
>> 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/

[petsc-dev] Negative blocksize

[Václav Hapla via petsc-dev]

Is there any reason why PetscLayoutSetUp couldn't guarantee blocksize >= 1? I 
don't like the negative value being there forever requiring all that PetscAbs 
business. It seems to me it just complicates things unnecessarily.

Thanks,
Vaclav

Re: [petsc-dev] PETSc blame digest (next) 2019-06-20

[Václav Hapla via petsc-dev]

Yes, I think that's the reason we moved it to private :-)

Sometimes I see _Internal. I thought _Private is preferred for static functions 
visible only within a single object file?

Vaclav


20. června 2019 21:50:29 SELČ, "Smith, Barry F."  napsal:
>
>It HAS A hid_t argument! Making it public means making HDF5 includes
>public, means all PETSc applications have the HDF5 includes open in
>them. Likely it should just get _Private 
>
>   Barry
>
>
>On Jun 20, 2019, at 9:01 AM, Hapla Vaclav via petsc-dev
> wrote:
>> 
>> On 20 Jun 2019, at 15:56, Vaclav Hapla 
>wrote:
>>> 
>>>
>/home/sandbox/petsc/petsc.next-3/src/mat/impls/dense/seq/densehdf5.c:62:
>undefined reference to `PetscViewerHDF5Load'
>>> 
>>> Does it mean I need to change visibility of PetscViewerHDF5Load
>in isimpl.h to PETSC_EXTERN?
>>> Are you OK with that?
>> 
>> Yes, and when doing that, it needs a Developer level man page.
> 
> OK, thanks.
 
 So as a rule of thumb, every PETSC_EXTERN function should be
>documented, although in private headers?
 
 Then src/vec/is/utils/hdf5io.c should have
 #include  /*I "petsc/private/isimpl.h" I*/
 ?
 Looks a bit weird, doesn't it?
 
 I think there are countless cases petsc-wide which break this.
>>> 
>>> dev manual page 15 bullet 15:
>>> "private functions may need to be marked PETSC_EXTERN"
>>> There is an example of MatHeaderReplace. It hasn't a manpage.
>>> 
>> 
>> Well, I'm not against making it public (it originally was) and write
>a manpage, but then it should be also moved to the public header file.
>> 
>> Sorry for sending a few previous emails only to Jed.
>> 
>> Vaclav
>> 

Re: [petsc-dev] PETSC_VIEWER_*_() vs PetscOptionsGetViewer()

[Václav Hapla via petsc-dev]

28. května 2019 23:46:13 SELČ, "Smith, Barry F."  napsal:
>
>
>> On May 28, 2019, at 4:40 PM, Matthew Knepley 
>wrote:
>> 
>> On Tue, May 28, 2019 at 5:26 PM Smith, Barry F. via petsc-dev
> wrote:
>> 
>>   I have concerns. 
>> 
>>   Without the use of singletons 
>> 
>>-mat_view binary -vec_view binary
>> 
>>   will result in only the final object viewed being in the file
>binaryoutput? The idea behind the singletons is they provide continuity
>for the entire run. 
>> 
>>   Note that currently when also creating and destroying the viewers
>with the same name you only get the most recent stuff. In fact
>something like 
>> 
>>-mat_view hdf5:myfile 
>> 
>>   is likely now buggy since it will only save the most recent matrix
>viewed in the file the user might expect all the matrices in there.
>> 
>> you use
>> 
>>   0mat_view hdf5:myfile::append
>
>   And all the crap from yesterday's runs are also in the file?

You can View as many objects as you want (even of various classes) into the 
same hdf5 file, and they are stored by name, order is unimportant. Yes, I guess 
Matt is right you need append mode if you don't want to rewrite the file from 
scratch.

Likewise Load looks up by name and order doesn't matter.

You can also remove things (not implemented in petsc) but the file is actually 
not reduced in size (actually just links are invalidatef) until you pass it 
through h5repack which creates a new file with unlinked things omitted.

Vaclav

>
>> 
>> 
>>Matt
>>  
>> Perhaps PetscOptionsGetViewer() needs to register all viewers created
>with the destroy in PetscFinalize() and never have the user destroy
>them and attach them to the communicator so they get reused at the next
>call instead of creating a new one.
>> 
>>   Even if we do the above another problem is
>> 
>>-xxx_view xx:filename 
>> 
>> will be problematic if there are xxx in different communicators since
>if we attach them to a communicator we won't find them with a different
>communicator and will open the file again. I don't know how to fix
>this.
>> 
>>   I think the entire PetscOptionsGetViewer() business needs a bit
>more thought. At the moment it is a bit flawed. Making them
>non-singletons won't fix the flaws.
>> 
>> > BTW all PETSC_VIEWER_XXX_() manpages say "Creates a XXX PetscViewer
>shared by all processors in a communicator."
>> > This is apparently not true - they are singletons stashed to the
>communicator by MPI_Comm_set_attr() and next time reused if found using
>MPI_Comm_get_attr(), right?
>> > So it should be Returns, not Creates.
>> 
>>   This should be fixed in its own PR.
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> > On May 28, 2019, at 10:35 AM, Hapla Vaclav via petsc-dev
> wrote:
>> > 
>> > Let me follow up discussion on creating/controlling viewers from
>options.
>> > 
>> > Barry agrees to rename PetscOptionsGetViewer() to
>PetscViewerCreateFromOptions() in Issue #291.
>> > 
>> > But now I can see a problem: it mixes Get and Create behavior, as
>it returns the singleton provided by PETSC_VIEWER_*_() if possible,
>otherwise creates a new viewer using PetscViewerCreate(). So actually
>both names PetscOptionsGetViewer() and PetscViewerCreateFromOptions()
>are confusing.
>> > 
>> > I think this design is unnecessarily complicated and not really
>useful.
>> > I don't see any advantage of reusing the singleton in this context.
>> > And leads to some IMHO unexpected behavior:
>> > * -myviewer hdf5:: and -myviewer hdf5 is not the same! I didn't
>know that but hdf5:: creates a new viewer and hdf5 reuses the
>singleton.
>> > * Any properties (including options prefix) set to the viewer
>returned by PetscOptionsGetViewer() actually affect the singleton and
>vice versa.
>> >   (See https://bitbucket.org/petsc/petsc/commits/324f959)
>> > 
>> > So in my opinion PetscOptionsGetViewer()
>> > * should really be renamed PetscViewerCreateFromOptions(),
>> > * should _always_ return a new instance and call
>PetscViewerSetFromOptions() on it,
>> > * could also set the passed prefix to the viewer, i.e.
>PetscViewerCreateFromOptions(comm, options, "pre_", ...) would result
>in the viewer having prefix pre_ 
>> > 
>> > Do you think it would break anything?
>> > 
>> > Thanks,
>> > Vaclav
>> > 
>> > BTW all PETSC_VIEWER_XXX_() manpages say "Creates a XXX PetscViewer
>shared by all processors in a communicator."
>> > This is apparently not true - they are singletons stashed to the
>communicator by MPI_Comm_set_attr() and next time reused if found using
>MPI_Comm_get_attr(), right?
>> > So it should be Returns, not Creates.
>> 
>> 
>> 
>> -- 
>> 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/

Re: [petsc-dev] [petsc-maint] circular dependency [nightlybuilds did not catch]

[Václav Hapla via petsc-dev]

4. května 2019 14:21:31 GMT+03:00, Jed Brown  napsal:
>Noting this historic event of Barry endorsing the addition of a new
>acronym with no specific demonstrated need.
>
>Note that most/all packages contain objects other that that which they
>are named after.  ksp/pc/, dm/label/, mat/partition/, snes/linesearch,
>etc.

At least DM contains Labels, KSP contains PC, MatPartitioning contains Mat, 
SNES contains Linesearch, right?
Although in case of pc, I think it deserves 1st level.

Whereas e.g. Layout, SF, Section do not contain IS and also otherwise they are 
basically unrelated except they all arrange some kind of index mapping. And 
there are multiple utils ar different levels and nobody knows where to put 
what. Plus all those have absolutely nothing in common with Vec.

Vaclav

>
>"Smith, Barry F."  writes:
>
>>   Ok
>>
>>
>>> On May 4, 2019, at 12:45 AM, Václav Hapla
> wrote:
>>> 
>>> 
>>> 
>>> 4. května 2019 1:08:09 GMT+03:00, "Smith, Barry F."
> napsal:
 
 
> On May 3, 2019, at 5:00 PM, Hapla Vaclav
>
 wrote:
> 
> 
> 
> OK, so index, idx, other idea?
 
 I'm not sure index is that informative (and not expansive enough).
 petscdm.h means nothing, maybe something short that doesn't mean
 anything?
>>> 
>>> Ok, that directly suggests im. One can interpret is as index
>mapping/management.
>>> 
 
> 
> If we would have layout, is, sf, section in the same subdir, I
>would
 move there also ao and ltog.
 
 Sure
 
> 
> What about the headers - I guess having all those classes in one
 would be easier to handle and avoid circular dependencies, and
>would
 reflect the directory structure. But should we keep separate
 petsc{ao,is,sf}.h, then I would suggest also separate
 petsc{layout,section,ltog}.h
 
 Separate is better.
 
> 
> When we are at it, why we sometimes have types.h and
>sometimes
 not?
 
 We add these "as needed"; Jed can explain better exactly when they
>are
 needed.
 
> 
> Vaclav
> 
> (added CC to petsc-dev)
> 
>> 
>> 
>>> map
>>> imap
>>> idxmap
>>> ... or something alike.
>>> 
>>> Vaclav
>>> 
> 
> Vaclav
> 
>> 
>> Why not at lest make an additional level between Sys and Vec
>for
 those sectioning utilities? Would make more sense to me.
>> 
>> Vaclav

Re: [petsc-dev] [petsc-maint] circular dependency [nightlybuilds did not catch]

[Václav Hapla via petsc-dev]

4. května 2019 8:45:09 GMT+03:00, "Václav Hapla via petsc-dev" 
 napsal:
>
>
>4. května 2019 1:08:09 GMT+03:00, "Smith, Barry F."
> napsal:
>>
>>
>>> On May 3, 2019, at 5:00 PM, Hapla Vaclav 
>>wrote:
>>> 
>>> 
>>> 
>>> OK, so index, idx, other idea?
>>
>>I'm not sure index is that informative (and not expansive enough).
>>petscdm.h means nothing, maybe something short that doesn't mean
>>anything?
>
>Ok, that directly suggests im. One can interpret is as index
>mapping/management.

... i is also integer, m is also methods ;-)

>
>>
>>> 
>>> If we would have layout, is, sf, section in the same subdir, I would
>>move there also ao and ltog.
>>
>>  Sure
>>
>>> 
>>> What about the headers - I guess having all those classes in one
>>would be easier to handle and avoid circular dependencies, and would
>>reflect the directory structure. But should we keep separate
>>petsc{ao,is,sf}.h, then I would suggest also separate
>>petsc{layout,section,ltog}.h
>>
>>  Separate is better.
>>
>>> 
>>> When we are at it, why we sometimes have types.h and
>sometimes
>>not?
>>
>>We add these "as needed"; Jed can explain better exactly when they are
>>needed.
>>
>>> 
>>> Vaclav
>>> 
>>> (added CC to petsc-dev)
>>> 
>>>> 
>>>> 
>>>>> map
>>>>> imap
>>>>> idxmap
>>>>> ... or something alike.
>>>>> 
>>>>> Vaclav
>>>>> 
>>>>>>> 
>>>>>>> Vaclav
>>>>>>> 
>>>>>>>> 
>>>>>>>> Why not at lest make an additional level between Sys and Vec
>for
>>those sectioning utilities? Would make more sense to me.
>>>>>>>> 
>>>>>>>> Vaclav

Re: [petsc-dev] [petsc-maint] circular dependency [nightlybuilds did not catch]

[Václav Hapla via petsc-dev]

4. května 2019 1:08:09 GMT+03:00, "Smith, Barry F."  napsal:
>
>
>> On May 3, 2019, at 5:00 PM, Hapla Vaclav 
>wrote:
>> 
>> 
>> 
>> OK, so index, idx, other idea?
>
>I'm not sure index is that informative (and not expansive enough).
>petscdm.h means nothing, maybe something short that doesn't mean
>anything?

Ok, that directly suggests im. One can interpret is as index mapping/management.

>
>> 
>> If we would have layout, is, sf, section in the same subdir, I would
>move there also ao and ltog.
>
>  Sure
>
>> 
>> What about the headers - I guess having all those classes in one
>would be easier to handle and avoid circular dependencies, and would
>reflect the directory structure. But should we keep separate
>petsc{ao,is,sf}.h, then I would suggest also separate
>petsc{layout,section,ltog}.h
>
>  Separate is better.
>
>> 
>> When we are at it, why we sometimes have types.h and sometimes
>not?
>
>We add these "as needed"; Jed can explain better exactly when they are
>needed.
>
>> 
>> Vaclav
>> 
>> (added CC to petsc-dev)
>> 
>>> 
>>> 
 map
 imap
 idxmap
 ... or something alike.
 
 Vaclav
 
>> 
>> Vaclav
>> 
>>> 
>>> Why not at lest make an additional level between Sys and Vec for
>those sectioning utilities? Would make more sense to me.
>>> 
>>> Vaclav

Re: [petsc-dev] Checkpoint-restart with DMPlex objects

[Václav Hapla via petsc-dev]

Thanks Karli! That should be it.

Vaclav


On 18 December 2018 16:48:30 GMT+01:00, Karl Rupp  wrote:
>
>
>> 
>> I have not quickly found how is that "VTK ordering" defined but I 
>> hopefully it's a well-defined unambiguous cell-local numbering. I
>will 
>> try to find it out soon and get back to you.
>
>Hope this helps:
>https://www.vtk.org/wp-content/uploads/2015/04/file-formats.pdf
>(page 9)
>
>Best regards,
>Karli