Re: [petsc-dev] OpenMP

[Junchao Zhang]

On Sat, Nov 6, 2021 at 3:51 PM Mark Adams  wrote:

> Yea, that is a bit inscrutable, but I see mumps is the main/only user of
> this:
>
> /* if using PETSc OpenMP support, we only call MUMPS on master ranks.
> Before/after the call, we change/restore CPUs the master ranks can run on */
>
> And I see _OPENMP is a macro for the release date (mm) of the OMP
> version. It's not clear what the v5.0 is (
> https://www.openmp.org/specifications/)
>
{200505,"2.5"},{200805,"3.0"},{201107,"3.1"},{201307,"4.0"},{201511,"4.5"},{201811,"5.0"},{202011,"5.1"}

On Sat, Nov 6, 2021 at 4:27 PM Junchao Zhang 
> wrote:
>
>>
>>
>> On Sat, Nov 6, 2021 at 5:51 AM Mark Adams  wrote:
>>
>>> Two questions on OMP:
>>>
>>> * Can I test for the version of OMP? I want >= 5 and I see this, which
>>> looks promising:
>>> include/petscsys.h:#elif defined(_OPENMP) && *_OPENMP >= 201307* &&
>>> !defined(_WIN32)
>>>
>>> * What is the difference between HAVE_OPENMP and
>>> HAVE_OPENMP_SUPPORT.
>>>
>>> # this is different from HAVE_OPENMP. HAVE_OPENMP_SUPPORT checks if we
>> have facilities to support
>> # running PETSc in flat-MPI mode and third party libraries in MPI+OpenMP
>> hybrid mode
>> if self.mpi.found and self.mpi.support_mpi3_shm and self.pthread.found
>> and self.hwloc.found:
>> # Apple pthread does not provide this functionality
>> if self.function.check('pthread_barrier_init', libraries = 'pthread'):
>> self.addDefine('HAVE_OPENMP_SUPPORT', 1)
>>
>>
>>> Thanks,
>>> Mark
>>>
>>

Re: [petsc-dev] OpenMP

[Mark Adams]

Yea, that is a bit inscrutable, but I see mumps is the main/only user of
this:

/* if using PETSc OpenMP support, we only call MUMPS on master ranks.
Before/after the call, we change/restore CPUs the master ranks can run on */

And I see _OPENMP is a macro for the release date (mm) of the OMP
version. It's not clear what the v5.0 is (
https://www.openmp.org/specifications/)

On Sat, Nov 6, 2021 at 4:27 PM Junchao Zhang 
wrote:

>
>
> On Sat, Nov 6, 2021 at 5:51 AM Mark Adams  wrote:
>
>> Two questions on OMP:
>>
>> * Can I test for the version of OMP? I want >= 5 and I see this, which
>> looks promising:
>> include/petscsys.h:#elif defined(_OPENMP) && *_OPENMP >= 201307* &&
>> !defined(_WIN32)
>>
>> * What is the difference between HAVE_OPENMP and
>> HAVE_OPENMP_SUPPORT.
>>
>> # this is different from HAVE_OPENMP. HAVE_OPENMP_SUPPORT checks if we
> have facilities to support
> # running PETSc in flat-MPI mode and third party libraries in MPI+OpenMP
> hybrid mode
> if self.mpi.found and self.mpi.support_mpi3_shm and self.pthread.found and
> self.hwloc.found:
> # Apple pthread does not provide this functionality
> if self.function.check('pthread_barrier_init', libraries = 'pthread'):
> self.addDefine('HAVE_OPENMP_SUPPORT', 1)
>
>
>> Thanks,
>> Mark
>>
>

Re: [petsc-dev] OpenMP

[Junchao Zhang]

On Sat, Nov 6, 2021 at 5:51 AM Mark Adams  wrote:

> Two questions on OMP:
>
> * Can I test for the version of OMP? I want >= 5 and I see this, which
> looks promising:
> include/petscsys.h:#elif defined(_OPENMP) && *_OPENMP >= 201307* &&
> !defined(_WIN32)
>
> * What is the difference between HAVE_OPENMP and
> HAVE_OPENMP_SUPPORT.
>
> # this is different from HAVE_OPENMP. HAVE_OPENMP_SUPPORT checks if we
have facilities to support
# running PETSc in flat-MPI mode and third party libraries in MPI+OpenMP
hybrid mode
if self.mpi.found and self.mpi.support_mpi3_shm and self.pthread.found and
self.hwloc.found:
# Apple pthread does not provide this functionality
if self.function.check('pthread_barrier_init', libraries = 'pthread'):
self.addDefine('HAVE_OPENMP_SUPPORT', 1)


> Thanks,
> Mark
>

Re: [petsc-dev] [DocTip!] #2: Aiming for self-updating docs

[Matthew Knepley]

On Sat, Nov 6, 2021 at 10:34 AM Patrick Sanan 
wrote:

>
>
> Am Fr., 5. Nov. 2021 um 19:18 Uhr schrieb Lawrence Mitchell  >:
>
>>
>> > On 5 Nov 2021, at 15:25, Patrick Sanan  wrote:
>> >
>> > Good question. We don't have any that start at specific line numbers,
>> currently, as it is indeed too brittle - I suspect I removed some that were
>> there at one point.
>> >
>> > The inclusions essentially all use :start-at: to specify a line to
>> match. Ideally you'd also use :end-at: to specify where to stop, but some
>> short snippets do instead specify a number of lines. Note that a
>> practically handy option is :append:, as in this example where you are
>> trying to excerpt the function PetscError(), and you can match on the
>> PetscFunctionReturn(0) and then re-add the closing brace.
>> >
>> > .. literalinclude::/../src/sys/error/err.c
>> > :start-at: PetscErrorCode PetscError(
>> > :end-at: PetscFunctionReturn(0)
>> > :append: }
>>
>> FWIW, this feels a bit like trying to reinvent WEB.
>>
> I don't know what WEB is, but if you're saying that this is kinda clunky,
> yes it definitely is - my only contention is that it's better than
> copy-pasting code and output.  I'm not sure if there's an easier and/or
> better way with Sphinx.
>

WEB was the futuristic documentation idea of Don Knuth.

  Thanks,

 Matt


>
>> Doing actual literate documentation of key tutorial programs would be a
>> nice way of doing this, but I realise that's a lot more effort.
>>
> This is still a hope/plan to go into doc/tutorials - follow the deal.ii
> model for a small number of key examples. Matt has done a couple of pages
> there already, in this direction.
>
> Lawrence
>
>

-- 
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] [DocTip!] #3 CI docs build and preview

[Mark Adams]

This is nice.
I see "view latest app" in the pipeline box and you can edit/commit in the
browser also.

On Sat, Nov 6, 2021 at 10:10 AM Patrick Sanan 
wrote:

> All MRs now build all the documentation. This is done with the
> "docs-review" job (defined in .gitlab-ci.yml ) . There is special logic
> associated with the "docs-only" label: if you add this to your MR, the
> usual heavy library tests will be skipped, and the docs will be built
> without you having to manually "un-pause" the pipelines each time you
> update the MR.
>
> Jed showed us a nice approach where the results of this build are deployed
> to GitLab pages, allowing us to use a "Review App" to see the documentation
> build corresponding to the MR branch.
>
> Practically, this allows you to simply click "view app" on the MR page and
> you'll be taken to a complete version of the site (as on petsc.org).
>
> You may still want to build the docs locally if you want to iterate (more)
> quickly, as this allows you to quickly regenerate them after making changes
> (as opposed to the many minutes docs-review takes), and keep open a web
> browser pointing to your local build.
>
> Unfortunately, I don't know a simple way to reliably preview a single .rst
> file (as you might be used to from working with some Markdown-based tools).
>

Re: [petsc-dev] [DocTip!] #2: Aiming for self-updating docs

[Patrick Sanan]

Am Fr., 5. Nov. 2021 um 19:18 Uhr schrieb Lawrence Mitchell :

>
> > On 5 Nov 2021, at 15:25, Patrick Sanan  wrote:
> >
> > Good question. We don't have any that start at specific line numbers,
> currently, as it is indeed too brittle - I suspect I removed some that were
> there at one point.
> >
> > The inclusions essentially all use :start-at: to specify a line to
> match. Ideally you'd also use :end-at: to specify where to stop, but some
> short snippets do instead specify a number of lines. Note that a
> practically handy option is :append:, as in this example where you are
> trying to excerpt the function PetscError(), and you can match on the
> PetscFunctionReturn(0) and then re-add the closing brace.
> >
> > .. literalinclude::/../src/sys/error/err.c
> > :start-at: PetscErrorCode PetscError(
> > :end-at: PetscFunctionReturn(0)
> > :append: }
>
> FWIW, this feels a bit like trying to reinvent WEB.
>
I don't know what WEB is, but if you're saying that this is kinda clunky,
yes it definitely is - my only contention is that it's better than
copy-pasting code and output.  I'm not sure if there's an easier and/or
better way with Sphinx.

>
> Doing actual literate documentation of key tutorial programs would be a
> nice way of doing this, but I realise that's a lot more effort.
>
This is still a hope/plan to go into doc/tutorials - follow the deal.ii
model for a small number of key examples. Matt has done a couple of pages
there already, in this direction.

Lawrence

[petsc-dev] [DocTip!] #3 CI docs build and preview

[Patrick Sanan]

All MRs now build all the documentation. This is done with the
"docs-review" job (defined in .gitlab-ci.yml ) . There is special logic
associated with the "docs-only" label: if you add this to your MR, the
usual heavy library tests will be skipped, and the docs will be built
without you having to manually "un-pause" the pipelines each time you
update the MR.

Jed showed us a nice approach where the results of this build are deployed
to GitLab pages, allowing us to use a "Review App" to see the documentation
build corresponding to the MR branch.

Practically, this allows you to simply click "view app" on the MR page and
you'll be taken to a complete version of the site (as on petsc.org).

You may still want to build the docs locally if you want to iterate (more)
quickly, as this allows you to quickly regenerate them after making changes
(as opposed to the many minutes docs-review takes), and keep open a web
browser pointing to your local build.

Unfortunately, I don't know a simple way to reliably preview a single .rst
file (as you might be used to from working with some Markdown-based tools).

[petsc-dev] OpenMP

[Mark Adams]

Two questions on OMP:

* Can I test for the version of OMP? I want >= 5 and I see this, which
looks promising:
include/petscsys.h:#elif defined(_OPENMP) && *_OPENMP >= 201307* &&
!defined(_WIN32)

* What is the difference between HAVE_OPENMP and
HAVE_OPENMP_SUPPORT.

Thanks,
Mark