Re: [petsc-dev] On remaining libMesh-PETsc fieldsplit interface cleanup
> On Apr 1, 2019, at 8:19 PM, Matthew Knepley via petsc-dev
> wrote:
>
> On Mon, Apr 1, 2019 at 9:12 PM Boris Boutkov via petsc-dev
> wrote:
> Hello all,
>
> I've been working on the libMesh - PETSc interface for utilizing
> gmg/fieldsplit on the command line by creating DMShells; things are seemingly
> in pretty good shape at this point, so thanks much for the support along the
> way!
>
> The last lingering issue of the implementation is that I still have a little
> bit of dependency on PETSc private/dmimpl.h. In short, during our
> implementation of DMCreateSubDM I try and get some of the parent DMs function
> pointers, specifically dm->ops->{coarsen, refine, createinterpolation,
> createrestriction, and createsubdm}, which then I set for the subDM using
> DMShellSet* by passing in the parent DM pointer directly.
>
> I'd like to remove this private dmimpl.h dependency but removing the header
> gives me compilation errors - "invalid use of incomplete type" pointing to
> PETsc DM struct for the above calls. As far as I understand it, this means
> that I would need public API similar to the DMShellSet* methods but now
> instead DMShellGet*.
>
> If the above's the case, any reason this doesn't exist yet outside of lack of
> prior need? And how much work would introducing this require? Or of course
> please let me know if there's some simple way around this that I may be
> missing.
>
> No, we just needed someone to ask. We will do this exactly like we do
> MATSHELL. We have to create an Enum that indexes
> the DM methods. Then you can pass the Enum value when you Set/Get the
> methods. Its not hard, just some coding. Want to try :)
Actually this is not the way DMShell works, DMShell works the way PCSHELL
works, each set function is its own function (for example
DMShellSetCreateGlobalVector) and there is no enum of operations (like
MatOperations). Given the current DMSHELL API it makes sense to just provide
DMShellGetXX() for each DM operation.
Barry
Well you may well ask, why we have two different approaches for different
PETSc objects/classes. I am asking. And well you may.
I don't have any rational for having two different approaches, lack of good
code reviews in the past? Should we evolve towards using the same approach for
all XXXSHELL subclasses in the future? Perhaps.
I
>
>Thanks,
>
> Matt
> Thanks as always for your time,
>
> - Boris
>
>
>
>
>
> --
> 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] On remaining libMesh-PETsc fieldsplit interface cleanup
Ok, I think I understand the strategy. It does sound easy enough, let me
just clean up a couple of things off my plate first and then I can give
this a swing.
Thanks again for the info,
- Boris
On 4/1/19 9:19 PM, Matthew Knepley wrote:
On Mon, Apr 1, 2019 at 9:12 PM Boris Boutkov via petsc-dev
mailto:petsc-dev@mcs.anl.gov>> wrote:
Hello all,
I've been working on the libMesh - PETSc interface for utilizing
gmg/fieldsplit on the command line by creating DMShells; things
are seemingly in pretty good shape at this point, so thanks much
for the support along the way!
The last lingering issue of the implementation is that I still
have a little bit of dependency on PETSc private/dmimpl.h. In
short, during our implementation of DMCreateSubDM I try and get
some of the parent DMs function pointers, specifically
dm->ops->{coarsen, refine, createinterpolation,
createrestriction,and createsubdm}, which then I set for the subDM
using DMShellSet* by passing in the parent DM pointer directly.
I'd like to remove this private dmimpl.h dependency but removing
the header gives me compilation errors - "invalid use of
incomplete type" pointing to PETsc DM struct for the above calls.
As far as I understand it, this means that I would need public API
similar to the DMShellSet* methods but now instead DMShellGet*.
If the above's the case, any reason this doesn't exist yet outside
of lack of prior need? And how much work would introducing this
require? Or of course please let me know if there's some simple
way around this that I may be missing.
No, we just needed someone to ask. We will do this exactly like we do
MATSHELL. We have to create an Enum that indexes
the DM methods. Then you can pass the Enum value when you Set/Get the
methods. Its not hard, just some coding. Want to try :)
Thanks,
Matt
Thanks as always for your time,
- Boris
--
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] Elemental & 64-bit int
On Tue, 2 Apr 2019, Victor Eijkhout via petsc-dev wrote: > > > > On Apr 1, 2019, at 8:02 PM, Balay, Satish wrote: > > > > On Tue, 2 Apr 2019, Victor Eijkhout via petsc-dev wrote: > > > >> Configuring with elemental & 64-bit integers: > >> > >> Cannot use elemental with 64 bit BLAS/Lapack indices > >> > >> This used to work in 3.10. What changed? > > > > with MKL? > > Yes. > > > > > Try: > > > > https://bitbucket.org/petsc/petsc/pull-requests/1489/revert-commit-69ab9685009e-so-that-blas/diff#Lconfig/BuildSystem/config/packages/BlasLapack.pyF215T215 > > > > Sorry, I’m not that much into git. Can you spell out how I get this applied > and to what do I apply it to? Since its a single commit - you can: cd petsc-3.11.0 wget https://bitbucket.org/petsc/petsc/commits/6042f227ea50491e9afb70b084b0f7117c89ea5a/raw patch -Np1 < raw Satish
Re: [petsc-dev] Elemental & 64-bit int
> On Apr 1, 2019, at 8:02 PM, Balay, Satish wrote: > > On Tue, 2 Apr 2019, Victor Eijkhout via petsc-dev wrote: > >> Configuring with elemental & 64-bit integers: >> >> Cannot use elemental with 64 bit BLAS/Lapack indices >> >> This used to work in 3.10. What changed? > > with MKL? Yes. > > Try: > > https://bitbucket.org/petsc/petsc/pull-requests/1489/revert-commit-69ab9685009e-so-that-blas/diff#Lconfig/BuildSystem/config/packages/BlasLapack.pyF215T215 > Sorry, I’m not that much into git. Can you spell out how I get this applied and to what do I apply it to? Victor. > Satish
[petsc-dev] On remaining libMesh-PETsc fieldsplit interface cleanup
Hello all,
I've been working on the libMesh - PETSc interface for utilizing
gmg/fieldsplit on the command line by creating DMShells; things are
seemingly in pretty good shape at this point, so thanks much for the
support along the way!
The last lingering issue of the implementation is that I still have a
little bit of dependency on PETSc private/dmimpl.h. In short, during our
implementation of DMCreateSubDM I try and get some of the parent DMs
function pointers, specifically dm->ops->{coarsen, refine,
createinterpolation, createrestriction,and createsubdm}, which then I
set for the subDM using DMShellSet* by passing in the parent DM pointer
directly.
I'd like to remove this private dmimpl.h dependency but removing the
header gives me compilation errors - "invalid use of incomplete type"
pointing to PETsc DM struct for the above calls. As far as I understand
it, this means that I would need public API similar to the DMShellSet*
methods but now instead DMShellGet*.
If the above's the case, any reason this doesn't exist yet outside of
lack of prior need? And how much work would introducing this require? Or
of course please let me know if there's some simple way around this that
I may be missing.
Thanks as always for your time,
- Boris
Re: [petsc-dev] Elemental & 64-bit int
On Tue, 2 Apr 2019, Victor Eijkhout via petsc-dev wrote: > Configuring with elemental & 64-bit integers: > > Cannot use elemental with 64 bit BLAS/Lapack indices > > This used to work in 3.10. What changed? with MKL? Try: https://bitbucket.org/petsc/petsc/pull-requests/1489/revert-commit-69ab9685009e-so-that-blas/diff#Lconfig/BuildSystem/config/packages/BlasLapack.pyF215T215 Satish
[petsc-dev] Elemental & 64-bit int
Configuring with elemental & 64-bit integers: Cannot use elemental with 64 bit BLAS/Lapack indices This used to work in 3.10. What changed? Victor.
Re: [petsc-dev] git repo branches housekeeping
On Mon, 1 Apr 2019, Hapla Vaclav wrote: > > - try to close as many branches as possible on the server [with each PR]. > > Do you mean to tick the checkbox > Close after the pull request is merged > when creating a PR? Or the person merging the PR would use the web interface to do this merge - and 'tick the checkbox' at that merge step. And I would scan branches weekly or [whenever I remember] to spot merged branches that were not deleted. Note: When a PR is from a fork - we manually create a local branch to track its progress through next. Such branches would have to be manually deleted. Satish
Re: [petsc-dev] git repo branches housekeeping
> On 1 Apr 2019, at 20:54, Balay, Satish via petsc-dev > wrote: > > On Mon, 1 Apr 2019, Jed Brown wrote: > >> "Balay, Satish" writes: >> >>> On Mon, 1 Apr 2019, Jed Brown via petsc-dev wrote: >>> "Smith, Barry F. via petsc-dev" writes: > This is, IMHO, a weakness of git. It is crazy to impose this type of > housekeeping directly on all 1000 users of a repository. Perhaps this should be the default: git config --global fetch.prune true >>> >>> or use 'git fetch -p' [ mentioned in my instructions]. I prefer >>> 'fetch' to 'pull' anyway [as it keeps my git prompt sane] - so this >>> works out well for me. >>> But, it would make it harder to recover if someone accidentally deletes a branch on the server. https://stackoverflow.com/a/40842589/33208 >>> >>> This updates the origin/* references to remote branches - but does not >>> delete locally checked out branches [if any] - they have to be >>> manually deleted [as mentioned in my instructions] >> >> Yes, but those are branches that a person has directly interacted with. >> The many other branches would be quietly pruned. > > Agree.. > > We could do: > > - try to close as many branches as possible on the server [with each PR]. Do you mean to tick the checkbox Close after the pull request is merged when creating a PR? Thanks, Vaclav > - recommend folks use 'git config --global fetch.prune true' or 'git fetch > -p' in their regular workflow. > - folks could do housekeeping on their clones (aka delete local branches) at > their own convenient schedule. > - and I'll continue to send the 'housekeeping' e-mail reminder after release. > > Satish
Re: [petsc-dev] git repo branches housekeeping
On Mon, 1 Apr 2019, Jed Brown wrote: > "Balay, Satish" writes: > > > On Mon, 1 Apr 2019, Jed Brown via petsc-dev wrote: > > > >> "Smith, Barry F. via petsc-dev" writes: > >> > >> >This is, IMHO, a weakness of git. It is crazy to impose this type of > >> > housekeeping directly on all 1000 users of a repository. > >> > >> Perhaps this should be the default: > >> > >> git config --global fetch.prune true > > > > or use 'git fetch -p' [ mentioned in my instructions]. I prefer > > 'fetch' to 'pull' anyway [as it keeps my git prompt sane] - so this > > works out well for me. > > > >> > >> But, it would make it harder to recover if someone accidentally deletes > >> a branch on the server. > >> > >> https://stackoverflow.com/a/40842589/33208 > > > > This updates the origin/* references to remote branches - but does not > > delete locally checked out branches [if any] - they have to be > > manually deleted [as mentioned in my instructions] > > Yes, but those are branches that a person has directly interacted with. > The many other branches would be quietly pruned. Agree.. We could do: - try to close as many branches as possible on the server [with each PR]. - recommend folks use 'git config --global fetch.prune true' or 'git fetch -p' in their regular workflow. - folks could do housekeeping on their clones (aka delete local branches) at their own convenient schedule. - and I'll continue to send the 'housekeeping' e-mail reminder after release. Satish
Re: [petsc-dev] git repo branches housekeeping
"Balay, Satish" writes: > On Mon, 1 Apr 2019, Jed Brown via petsc-dev wrote: > >> "Smith, Barry F. via petsc-dev" writes: >> >> >This is, IMHO, a weakness of git. It is crazy to impose this type of >> > housekeeping directly on all 1000 users of a repository. >> >> Perhaps this should be the default: >> >> git config --global fetch.prune true > > or use 'git fetch -p' [ mentioned in my instructions]. I prefer > 'fetch' to 'pull' anyway [as it keeps my git prompt sane] - so this > works out well for me. > >> >> But, it would make it harder to recover if someone accidentally deletes >> a branch on the server. >> >> https://stackoverflow.com/a/40842589/33208 > > This updates the origin/* references to remote branches - but does not > delete locally checked out branches [if any] - they have to be > manually deleted [as mentioned in my instructions] Yes, but those are branches that a person has directly interacted with. The many other branches would be quietly pruned.
Re: [petsc-dev] Would this make sense?
Matthew Knepley via petsc-dev writes: > https://ford-foundation-6.forms.fm/digital-infrastructure-research-rfp/forms/4770 "Submissions were due on Jun 13, 2018 at 9:59pm." > Perhaps we would get funds to > > 1) Cloudize our usage, along the lines Jed has been going > > 2) Harden the automatic testing infrastructure, maybe incorporate > performance regression > > 3) Bring the tutorials infrastructure into the 21st century GSoC could be appropriate. The big issue is people. Most developers here are not intrinsically motivated by devops, and people with devops expertise can make real money so what makes devops for PETSc more interesting than devops in any other setting?
Re: [petsc-dev] git repo branches housekeeping
On Mon, 1 Apr 2019, Jed Brown via petsc-dev wrote: > "Smith, Barry F. via petsc-dev" writes: > > >This is, IMHO, a weakness of git. It is crazy to impose this type of > > housekeeping directly on all 1000 users of a repository. > > Perhaps this should be the default: > > git config --global fetch.prune true or use 'git fetch -p' [ mentioned in my instructions]. I prefer 'fetch' to 'pull' anyway [as it keeps my git prompt sane] - so this works out well for me. > > But, it would make it harder to recover if someone accidentally deletes > a branch on the server. > > https://stackoverflow.com/a/40842589/33208 This updates the origin/* references to remote branches - but does not delete locally checked out branches [if any] - they have to be manually deleted [as mentioned in my instructions] Satish
Re: [petsc-dev] git repo branches housekeeping
"Smith, Barry F. via petsc-dev" writes: >This is, IMHO, a weakness of git. It is crazy to impose this type of > housekeeping directly on all 1000 users of a repository. Perhaps this should be the default: git config --global fetch.prune true But, it would make it harder to recover if someone accidentally deletes a branch on the server. https://stackoverflow.com/a/40842589/33208
Re: [petsc-dev] git repo branches housekeeping
"Balay, Satish via petsc-dev" writes: >> Would it make sense to make this cleanup in a regular basis? Once a PR is >> merged into master, what's the point of keeping the branch around until >> next release? It makes it heavier to search for a branch in Bitbucket, "git >> remote show origin" produces huge listing. >> I try hard myself of remembering to remove my merged branches, or select >> "close source branch" when I make the PR. > > Well I think the prior thought was - if some additional fixes are > needed to that branch after merge to master - its good to keep it > around. But I guess this use-case is rare.. Yeah, pretty rare and the branch name is mentioned in the merge commit so it can be recreated when needed. (Doing so is desirable because it allows in-development branches to obtain a bug fix without possibly unrelated features from 'master'.)
Re: [petsc-dev] git repo branches housekeeping
> On Apr 1, 2019, at 10:37 AM, Balay, Satish via petsc-dev > wrote: > > On Mon, 1 Apr 2019, Lisandro Dalcin wrote: > >> On Fri, 29 Mar 2019 at 19:22, Balay, Satish via petsc-dev < >> petsc-dev@mcs.anl.gov> wrote: >> >>> ref: https://lists.mcs.anl.gov/pipermail/petsc-dev/2018-April/022748.html >>> >>> I've deleted all development branches that are already merged into >>> maint (v3.11) from https://bitbucket.org/petsc/petsc >>> >>> >> Would it make sense to make this cleanup in a regular basis? Once a PR is >> merged into master, what's the point of keeping the branch around until >> next release? It makes it heavier to search for a branch in Bitbucket, "git >> remote show origin" produces huge listing. >> I try hard myself of remembering to remove my merged branches, or select >> "close source branch" when I make the PR. > > Well I think the prior thought was - if some additional fixes are > needed to that branch after merge to master - its good to keep it > around. But I guess this use-case is rare.. > > Also - this cleanup can be done perhaps easily on the server [by > someone who can check on it regularly - as doing this when closing PR > cannot be automated] - but folk would have to do this on their clones > too [as cleanup on the server does not automatically do cleanup in > clones]. This is, IMHO, a weakness of git. It is crazy to impose this type of housekeeping directly on all 1000 users of a repository. Barry > Satish
Re: [petsc-dev] git repo branches housekeeping
On Mon, 1 Apr 2019, Lisandro Dalcin wrote: > On Fri, 29 Mar 2019 at 19:22, Balay, Satish via petsc-dev < > petsc-dev@mcs.anl.gov> wrote: > > > ref: https://lists.mcs.anl.gov/pipermail/petsc-dev/2018-April/022748.html > > > > I've deleted all development branches that are already merged into > > maint (v3.11) from https://bitbucket.org/petsc/petsc > > > > > Would it make sense to make this cleanup in a regular basis? Once a PR is > merged into master, what's the point of keeping the branch around until > next release? It makes it heavier to search for a branch in Bitbucket, "git > remote show origin" produces huge listing. > I try hard myself of remembering to remove my merged branches, or select > "close source branch" when I make the PR. Well I think the prior thought was - if some additional fixes are needed to that branch after merge to master - its good to keep it around. But I guess this use-case is rare.. Also - this cleanup can be done perhaps easily on the server [by someone who can check on it regularly - as doing this when closing PR cannot be automated] - but folk would have to do this on their clones too [as cleanup on the server does not automatically do cleanup in clones]. Satish
Re: [petsc-dev] Checking for valid C linker flags with Intel 19 on Cygwin
Thanks for the confirmation. Here is the PR for this change.
https://bitbucket.org/petsc/petsc/pull-requests/1484/win-update-containsinvalidflag-with-icc-19/diff
Satish
On Mon, 1 Apr 2019, Tim Steinhoff via petsc-dev wrote:
> Satish, that should be exactly it. Thanks!
>
> Am Mo., 1. Apr. 2019 um 16:04 Uhr schrieb Balay, Satish :
> >
> > I guess the following change will work with this compiler?
> >
> > diff --git a/config/BuildSystem/config/setCompilers.py
> > b/config/BuildSystem/config/setCompilers.py
> > index 3a616f0318..edd11894d7 100644
> > --- a/config/BuildSystem/config/setCompilers.py
> > +++ b/config/BuildSystem/config/setCompilers.py
> > @@ -1004,7 +1004,7 @@ class Configure(config.base.Configure):
> > output.find('not recognized') >= 0 or output.find('not
> > recognised') >= 0 or
> > output.find('unknown option') >= 0 or output.find('unknown flag')
> > >= 0 or output.find('Unknown switch') >= 0 or
> > output.find('ignoring option') >= 0 or output.find('ignored') >= 0
> > or
> > -output.find('argument unused') >= 0 or
> > +output.find('argument unused') >= 0 or output.find('not
> > supported') >= 0 or
> > # When checking for the existence of 'attribute'
> > output.find('is unsupported and will be skipped') >= 0 or
> > output.find('illegal option') >= 0 or output.find('Invalid
> > option') >= 0 or
> >
> >
> > Satish
> >
> > On Mon, 1 Apr 2019, Tim Steinhoff via petsc-dev wrote:
> >
> > > Hi,
> > >
> > > we moved from Intel 16 to Intel 19 compiler on Cygwin and it seems
> > > that Intel has changed their error message, when PETSc is testing for
> > > rpath flag.
> > >
> > > Intel 16 - PETSc rejects the flag correctly:
> > > stdout: icl: command line warning #10157: ignoring option '/W';
> > > argument is of wrong type
> > > Rejecting C linker flag -Wl,-rpath,/reps/petsc.git due to
> > >
> > > Now with Intel 19, PETSc thinks it is valid despite the warning message:
> > > stdout: icl: command line warning #10148: option
> > > '/Wl,-rpath,/home/jac/reps/petsc/petsc.git' not supported
> > > Valid C linker flag -Wl,-rpath,/home/jac/reps/petsc/petsc.git
> > >
> > > This leads to PETSc not recognizing that rpath is actually not
> > > supported which will lead to problems later.
> > >
> > > Could you please add the new message to the check in
> > > containsInvalidFlag (setCompilers.py) or should I create a PR?
> > >
> > > Thanks and kind regards,
> > >
> > > Volker
> > >
> >
>
Re: [petsc-dev] Checking for valid C linker flags with Intel 19 on Cygwin
I guess the following change will work with this compiler?
diff --git a/config/BuildSystem/config/setCompilers.py
b/config/BuildSystem/config/setCompilers.py
index 3a616f0318..edd11894d7 100644
--- a/config/BuildSystem/config/setCompilers.py
+++ b/config/BuildSystem/config/setCompilers.py
@@ -1004,7 +1004,7 @@ class Configure(config.base.Configure):
output.find('not recognized') >= 0 or output.find('not recognised') >=
0 or
output.find('unknown option') >= 0 or output.find('unknown flag') >= 0
or output.find('Unknown switch') >= 0 or
output.find('ignoring option') >= 0 or output.find('ignored') >= 0 or
-output.find('argument unused') >= 0 or
+output.find('argument unused') >= 0 or output.find('not supported') >=
0 or
# When checking for the existence of 'attribute'
output.find('is unsupported and will be skipped') >= 0 or
output.find('illegal option') >= 0 or output.find('Invalid option') >=
0 or
Satish
On Mon, 1 Apr 2019, Tim Steinhoff via petsc-dev wrote:
> Hi,
>
> we moved from Intel 16 to Intel 19 compiler on Cygwin and it seems
> that Intel has changed their error message, when PETSc is testing for
> rpath flag.
>
> Intel 16 - PETSc rejects the flag correctly:
> stdout: icl: command line warning #10157: ignoring option '/W';
> argument is of wrong type
> Rejecting C linker flag -Wl,-rpath,/reps/petsc.git due to
>
> Now with Intel 19, PETSc thinks it is valid despite the warning message:
> stdout: icl: command line warning #10148: option
> '/Wl,-rpath,/home/jac/reps/petsc/petsc.git' not supported
> Valid C linker flag -Wl,-rpath,/home/jac/reps/petsc/petsc.git
>
> This leads to PETSc not recognizing that rpath is actually not
> supported which will lead to problems later.
>
> Could you please add the new message to the check in
> containsInvalidFlag (setCompilers.py) or should I create a PR?
>
> Thanks and kind regards,
>
> Volker
>
Re: [petsc-dev] [petsc-checkbuilds] PETSc blame digest (next) 2019-03-20
Thanks! Van: Balay, Satish Verzonden: vrijdag 29 maart 2019 14:46 Aan: Bas van 't Hof CC: petsc-dev; PETSc checkBuilds Onderwerp: Re: [petsc-checkbuilds] PETSc blame digest (next) 2019-03-20 This issue is fixed by Matt and the PR is already merged in. https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbitbucket.org%2Fpetsc%2Fpetsc%2Fpull-requests%2F1453%2Fsys-extension-to-the-xml-logging-system%2Fcommits&data=02%7C01%7Cbas.vanthof%40vortech.nl%7Ca01553caa6d74b91ae8d08d6b44ce93c%7C5fe8f8070fe44cdf8dc636475a0b8555%7C0%7C0%7C636894639765691115&sdata=vMOafaTi9w16wAfMFMcfNhq8phTC0P7toLLVQ4CRFf4%3D&reserved=0 Satish On Fri, 29 Mar 2019, Bas van 't Hof via petsc-checkbuilds wrote: > Dear PETSc development team, > > My apologies for not noticing this mail before. I think the > problem only occured with the option --with-mpi=0. > > Attached, please find the original patch and an additional patch that > should remedy the problem. > > Regards, > > Bas van 't Hof > > On 20-03-19 13:28, PETSc checkBuilds wrote: > > > > Dear PETSc developer, > > > > This email contains listings of contributions attributed to you by > > `git blame` that caused compiler errors or warnings in PETSc automated > > testing. Follow the links to see the full log files. Please attempt to fix > > the issues promptly or let us know at petsc-dev@mcs.anl.gov if you are > > unable > > to resolve the issues. > > > > Thanks, > >The PETSc development team > > > > > > > > warnings attributed to commit > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbitbucket.org%2Fpetsc%2Fpetsc%2Fcommits%2F36763ca&data=02%7C01%7Cbas.vanthof%40vortech.nl%7Ca01553caa6d74b91ae8d08d6b44ce93c%7C5fe8f8070fe44cdf8dc636475a0b8555%7C0%7C0%7C636894639765691115&sdata=AatMv46yOpNEcYcZ1jeDTeCrWAs874nhhUS7v%2FzC7aY%3D&reserved=0 > > Sys: Extension to the XML logging system > > > >include/petscsys.h:1199 > > > > [https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fftp.mcs.anl.gov%2Fpub%2Fpetsc%2Fnightlylogs%2Farchive%2F2019%2F03%2F20%2Fbuild_next_arch-linux-uni_crush.log&data=02%7C01%7Cbas.vanthof%40vortech.nl%7Ca01553caa6d74b91ae8d08d6b44ce93c%7C5fe8f8070fe44cdf8dc636475a0b8555%7C0%7C0%7C636894639765691115&sdata=A2v7RLml4CMwsJt7jNp%2Fa%2BqNT0A5FA%2BuVILtMYSj9Yo%3D&reserved=0] > >/sandbox/petsc/petsc.next-2/include/petscsys.h:1199:30: error: > > 'MPI_2DOUBLE_PRECISION' undeclared (first use in this function) > > > > > > To opt-out from receiving these messages - send a request to > > petsc-dev@mcs.anl.gov. >
