> 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
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
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
> 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.
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
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:
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.
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
> 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
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
"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
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
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
"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
"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"
> 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:
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
> >
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
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
@@
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.
20 matches
Mail list logo
