Re: [petsc-users] Could not execute "['git', 'rev-parse', '--git-dir']"

[Fande Kong]

The default git gives me:

*Could not execute "['git', 'rev-parse', '--git-dir']"*

when I am configuring PETSc.

The manually loaded *gits*  work just fine.


Fande,

On Wed, Apr 4, 2018 at 5:04 PM, Garvey, Cormac T 
wrote:

> I though it was fixed, yes I will look into it again.
>
> Do you get an error just doing a git clone on falcon1 and falcon2?
>
> On Wed, Apr 4, 2018 at 4:48 PM, Kong, Fande  wrote:
>
>> module load git/2.16.2-GCCcore-5.4.0"  also works.
>>
>> Could you somehow make the default git work as well? Hence we do not need
>> to have this extra "module load for git"
>>
>> Fande,
>>
>> On Wed, Apr 4, 2018 at 4:43 PM, Kong, Fande  wrote:
>>
>>> Thanks, Cormac,
>>>
>>> *module load git/1.8.5.2-GCC-4.8.3 *
>>>
>>> works for me.
>>>
>>> Did not try "module load git/2.16.2-GCCcore-5.4.0" yet.
>>>
>>> I will try, and get it back here.
>>>
>>>
>>>
>>> Fande
>>>
>>> On Wed, Apr 4, 2018 at 4:39 PM, Garvey, Cormac T 
>>> wrote:
>>>

 We needed to rebuilt git on the INL falcon cluster because github
 server changed such that it no longer accepted TLSv1.

 The default git on the falcon cluster /usr/bin/git is just a wrapper
 script, so users would not need to load any modules to
 use git.

 When you load load git on falcon1 or falcon2 does it still fail?

 module load git/2.16.2-GCCcore-5.4.0

 Thanks,
 Cormac.



 On Wed, Apr 4, 2018 at 4:28 PM, Kong, Fande  wrote:

> Hi Cormac,
>
> Do you know anything on "git"? How did you guys build git on the
> falcon1?  The default git on Falcon1 does not work with petsc any more.
>
>
> Fande,
>
>
>
> On Wed, Apr 4, 2018 at 4:20 PM, Satish Balay 
> wrote:
>
>> Ok - I don't think I have access to this OS.
>>
>> And I see its from 2009 [sure its enterprise os - with regular
>> backport updates]
>>
>> But its wierd that you have such a new version of git at /usr/bin/git
>>
>> From what we know so far - the problem appears to be some bad
>> interaction of python-2.6 with this old OS [i.e old glibc etc..] - and
>> this new git version [binary built locally or on a different OS and
>> installed locally ?].
>>
>> Satish
>>
>> On Wed, 4 Apr 2018, Kong, Fande wrote:
>>
>> >  moose]$ uname -a
>> > Linux falcon1 3.0.101-108.13-default #1 SMP Wed Oct 11 12:30:40 UTC
>> 2017
>> > (294ccfe) x86_64 x86_64 x86_64 GNU/Linux
>> >
>> >
>> > moose]$ lsb_release -a
>> > LSB Version:
>> > core-2.0-noarch:core-3.2-noarch:core-4.0-noarch:core-2.0-x86
>> _64:core-3.2-x86_64:core-4.0-x86_64:desktop-4.0-amd64:deskto
>> p-4.0-noarch:graphics-2.0-amd64:graphics-2.0-noarch:graphics
>> -3.2-amd64:graphics-3.2-noarch:graphics-4.0-amd64:graphics-4.0-noarch
>> > Distributor ID:SUSE LINUX
>> > Description:SUSE Linux Enterprise Server 11 (x86_64)
>> > Release:11
>> > Codename:n/a
>> >
>> >
>> >
>> > On Wed, Apr 4, 2018 at 4:08 PM, Satish Balay 
>> wrote:
>> >
>> > > On Wed, 4 Apr 2018, Satish Balay wrote:
>> > >
>> > > > On Wed, 4 Apr 2018, Satish Balay wrote:
>> > > >
>> > > > > was your '2.16.2' version installed from source?
>> > > >
>> > > > >>>
>> > > > Checking for program /usr/bin/git...found
>> > > > Defined make macro "GIT" to "git"
>> > > > Executing: git --version
>> > > > stdout: git version 2.16.2
>> > > > 
>> > > >
>> > > > I gues its the OS default package
>> > > >
>> > > > >
>> > > > Machine platform:
>> > > > ('Linux', 'falcon1', '3.0.101-108.13-default', '#1 SMP Wed Oct
>> 11
>> > > 12:30:40 UTC 2017 (294ccfe)', 'x86_64', 'x86_64')
>> > > > Python version:
>> > > > 2.6.9 (unknown, Aug  5 2016, 11:15:31)
>> > > > [GCC 4.3.4 [gcc-4_3-branch revision 152973]]
>> > > > 
>> > > >
>> > > > What OS/version is on this machine? I can try reproducing in a
>> VM
>> > >
>> > > It is strange that the kernel is old [3.0 - perhaps LTS OS] ,
>> python is
>> > > old [2.6] - but git is new? [2.16?]
>> > >
>> > > https://urldefense.proofpoint.com/v2/url?u=https-3A__
>> > > mirrors.edge.kernel.org_pub_software_scm_git_&d=DwIBAg&c=
>> > > 54IZrppPQZKX9mLzcGdPfFD1hxrcB__aEkJFOKJFd00&r=DUUt3SRGI0_
>> > > JgtNaS3udV68GRkgV4ts7XKfj2opmiCY&m=WF6ZxIh9Z9Hh2kYY0w70aNrgfPicp6
>> > > kgIh5BvezPiEY&s=KWMsO7XC0-pQuQ_mD03tNJWEpxSTATlZW_DmX0QofGw&e=
>> > > git-2.16.2.tar.gz  16-Feb-2018
>> 17:48
>> > > 7M
>> > >
>> > > Satish
>> > >
>> >
>>
>>
>


 --
 Cormac Garvey
 HPC Software Consultant
 Scientific Computing
 Idaho National Laboratory
 Ph: 208-526-6294


>>>
>>
>
>
> --
> Cormac Garvey
> HPC Software Consultant
> Scientific Computing
> Ida

Re: [petsc-users] Could not execute "['git', 'rev-parse', '--git-dir']"

[Garvey, Cormac T]

I though it was fixed, yes I will look into it again.

Do you get an error just doing a git clone on falcon1 and falcon2?

On Wed, Apr 4, 2018 at 4:48 PM, Kong, Fande  wrote:

> module load git/2.16.2-GCCcore-5.4.0"  also works.
>
> Could you somehow make the default git work as well? Hence we do not need
> to have this extra "module load for git"
>
> Fande,
>
> On Wed, Apr 4, 2018 at 4:43 PM, Kong, Fande  wrote:
>
>> Thanks, Cormac,
>>
>> *module load git/1.8.5.2-GCC-4.8.3 *
>>
>> works for me.
>>
>> Did not try "module load git/2.16.2-GCCcore-5.4.0" yet.
>>
>> I will try, and get it back here.
>>
>>
>>
>> Fande
>>
>> On Wed, Apr 4, 2018 at 4:39 PM, Garvey, Cormac T 
>> wrote:
>>
>>>
>>> We needed to rebuilt git on the INL falcon cluster because github server
>>> changed such that it no longer accepted TLSv1.
>>>
>>> The default git on the falcon cluster /usr/bin/git is just a wrapper
>>> script, so users would not need to load any modules to
>>> use git.
>>>
>>> When you load load git on falcon1 or falcon2 does it still fail?
>>>
>>> module load git/2.16.2-GCCcore-5.4.0
>>>
>>> Thanks,
>>> Cormac.
>>>
>>>
>>>
>>> On Wed, Apr 4, 2018 at 4:28 PM, Kong, Fande  wrote:
>>>
 Hi Cormac,

 Do you know anything on "git"? How did you guys build git on the
 falcon1?  The default git on Falcon1 does not work with petsc any more.


 Fande,



 On Wed, Apr 4, 2018 at 4:20 PM, Satish Balay  wrote:

> Ok - I don't think I have access to this OS.
>
> And I see its from 2009 [sure its enterprise os - with regular
> backport updates]
>
> But its wierd that you have such a new version of git at /usr/bin/git
>
> From what we know so far - the problem appears to be some bad
> interaction of python-2.6 with this old OS [i.e old glibc etc..] - and
> this new git version [binary built locally or on a different OS and
> installed locally ?].
>
> Satish
>
> On Wed, 4 Apr 2018, Kong, Fande wrote:
>
> >  moose]$ uname -a
> > Linux falcon1 3.0.101-108.13-default #1 SMP Wed Oct 11 12:30:40 UTC
> 2017
> > (294ccfe) x86_64 x86_64 x86_64 GNU/Linux
> >
> >
> > moose]$ lsb_release -a
> > LSB Version:
> > core-2.0-noarch:core-3.2-noarch:core-4.0-noarch:core-2.0-x86
> _64:core-3.2-x86_64:core-4.0-x86_64:desktop-4.0-amd64:deskto
> p-4.0-noarch:graphics-2.0-amd64:graphics-2.0-noarch:graphics
> -3.2-amd64:graphics-3.2-noarch:graphics-4.0-amd64:graphics-4.0-noarch
> > Distributor ID:SUSE LINUX
> > Description:SUSE Linux Enterprise Server 11 (x86_64)
> > Release:11
> > Codename:n/a
> >
> >
> >
> > On Wed, Apr 4, 2018 at 4:08 PM, Satish Balay 
> wrote:
> >
> > > On Wed, 4 Apr 2018, Satish Balay wrote:
> > >
> > > > On Wed, 4 Apr 2018, Satish Balay wrote:
> > > >
> > > > > was your '2.16.2' version installed from source?
> > > >
> > > > >>>
> > > > Checking for program /usr/bin/git...found
> > > > Defined make macro "GIT" to "git"
> > > > Executing: git --version
> > > > stdout: git version 2.16.2
> > > > 
> > > >
> > > > I gues its the OS default package
> > > >
> > > > >
> > > > Machine platform:
> > > > ('Linux', 'falcon1', '3.0.101-108.13-default', '#1 SMP Wed Oct 11
> > > 12:30:40 UTC 2017 (294ccfe)', 'x86_64', 'x86_64')
> > > > Python version:
> > > > 2.6.9 (unknown, Aug  5 2016, 11:15:31)
> > > > [GCC 4.3.4 [gcc-4_3-branch revision 152973]]
> > > > 
> > > >
> > > > What OS/version is on this machine? I can try reproducing in a VM
> > >
> > > It is strange that the kernel is old [3.0 - perhaps LTS OS] ,
> python is
> > > old [2.6] - but git is new? [2.16?]
> > >
> > > https://urldefense.proofpoint.com/v2/url?u=https-3A__
> > > mirrors.edge.kernel.org_pub_software_scm_git_&d=DwIBAg&c=
> > > 54IZrppPQZKX9mLzcGdPfFD1hxrcB__aEkJFOKJFd00&r=DUUt3SRGI0_
> > > JgtNaS3udV68GRkgV4ts7XKfj2opmiCY&m=WF6ZxIh9Z9Hh2kYY0w70aNrgfPicp6
> > > kgIh5BvezPiEY&s=KWMsO7XC0-pQuQ_mD03tNJWEpxSTATlZW_DmX0QofGw&e=
> > > git-2.16.2.tar.gz  16-Feb-2018
> 17:48
> > > 7M
> > >
> > > Satish
> > >
> >
>
>

>>>
>>>
>>> --
>>> Cormac Garvey
>>> HPC Software Consultant
>>> Scientific Computing
>>> Idaho National Laboratory
>>> Ph: 208-526-6294
>>>
>>>
>>
>


-- 
Cormac Garvey
HPC Software Consultant
Scientific Computing
Idaho National Laboratory
Ph: 208-526-6294

Re: [petsc-users] Could not execute "['git', 'rev-parse', '--git-dir']"

[Kong, Fande]

module load git/2.16.2-GCCcore-5.4.0"  also works.

Could you somehow make the default git work as well? Hence we do not need
to have this extra "module load for git"

Fande,

On Wed, Apr 4, 2018 at 4:43 PM, Kong, Fande  wrote:

> Thanks, Cormac,
>
> *module load git/1.8.5.2-GCC-4.8.3 *
>
> works for me.
>
> Did not try "module load git/2.16.2-GCCcore-5.4.0" yet.
>
> I will try, and get it back here.
>
>
>
> Fande
>
> On Wed, Apr 4, 2018 at 4:39 PM, Garvey, Cormac T 
> wrote:
>
>>
>> We needed to rebuilt git on the INL falcon cluster because github server
>> changed such that it no longer accepted TLSv1.
>>
>> The default git on the falcon cluster /usr/bin/git is just a wrapper
>> script, so users would not need to load any modules to
>> use git.
>>
>> When you load load git on falcon1 or falcon2 does it still fail?
>>
>> module load git/2.16.2-GCCcore-5.4.0
>>
>> Thanks,
>> Cormac.
>>
>>
>>
>> On Wed, Apr 4, 2018 at 4:28 PM, Kong, Fande  wrote:
>>
>>> Hi Cormac,
>>>
>>> Do you know anything on "git"? How did you guys build git on the
>>> falcon1?  The default git on Falcon1 does not work with petsc any more.
>>>
>>>
>>> Fande,
>>>
>>>
>>>
>>> On Wed, Apr 4, 2018 at 4:20 PM, Satish Balay  wrote:
>>>
 Ok - I don't think I have access to this OS.

 And I see its from 2009 [sure its enterprise os - with regular backport
 updates]

 But its wierd that you have such a new version of git at /usr/bin/git

 From what we know so far - the problem appears to be some bad
 interaction of python-2.6 with this old OS [i.e old glibc etc..] - and
 this new git version [binary built locally or on a different OS and
 installed locally ?].

 Satish

 On Wed, 4 Apr 2018, Kong, Fande wrote:

 >  moose]$ uname -a
 > Linux falcon1 3.0.101-108.13-default #1 SMP Wed Oct 11 12:30:40 UTC
 2017
 > (294ccfe) x86_64 x86_64 x86_64 GNU/Linux
 >
 >
 > moose]$ lsb_release -a
 > LSB Version:
 > core-2.0-noarch:core-3.2-noarch:core-4.0-noarch:core-2.0-x86
 _64:core-3.2-x86_64:core-4.0-x86_64:desktop-4.0-amd64:deskto
 p-4.0-noarch:graphics-2.0-amd64:graphics-2.0-noarch:graphics
 -3.2-amd64:graphics-3.2-noarch:graphics-4.0-amd64:graphics-4.0-noarch
 > Distributor ID:SUSE LINUX
 > Description:SUSE Linux Enterprise Server 11 (x86_64)
 > Release:11
 > Codename:n/a
 >
 >
 >
 > On Wed, Apr 4, 2018 at 4:08 PM, Satish Balay 
 wrote:
 >
 > > On Wed, 4 Apr 2018, Satish Balay wrote:
 > >
 > > > On Wed, 4 Apr 2018, Satish Balay wrote:
 > > >
 > > > > was your '2.16.2' version installed from source?
 > > >
 > > > >>>
 > > > Checking for program /usr/bin/git...found
 > > > Defined make macro "GIT" to "git"
 > > > Executing: git --version
 > > > stdout: git version 2.16.2
 > > > 
 > > >
 > > > I gues its the OS default package
 > > >
 > > > >
 > > > Machine platform:
 > > > ('Linux', 'falcon1', '3.0.101-108.13-default', '#1 SMP Wed Oct 11
 > > 12:30:40 UTC 2017 (294ccfe)', 'x86_64', 'x86_64')
 > > > Python version:
 > > > 2.6.9 (unknown, Aug  5 2016, 11:15:31)
 > > > [GCC 4.3.4 [gcc-4_3-branch revision 152973]]
 > > > 
 > > >
 > > > What OS/version is on this machine? I can try reproducing in a VM
 > >
 > > It is strange that the kernel is old [3.0 - perhaps LTS OS] ,
 python is
 > > old [2.6] - but git is new? [2.16?]
 > >
 > > https://urldefense.proofpoint.com/v2/url?u=https-3A__
 > > mirrors.edge.kernel.org_pub_software_scm_git_&d=DwIBAg&c=
 > > 54IZrppPQZKX9mLzcGdPfFD1hxrcB__aEkJFOKJFd00&r=DUUt3SRGI0_
 > > JgtNaS3udV68GRkgV4ts7XKfj2opmiCY&m=WF6ZxIh9Z9Hh2kYY0w70aNrgfPicp6
 > > kgIh5BvezPiEY&s=KWMsO7XC0-pQuQ_mD03tNJWEpxSTATlZW_DmX0QofGw&e=
 > > git-2.16.2.tar.gz  16-Feb-2018 17:48
 > > 7M
 > >
 > > Satish
 > >
 >


>>>
>>
>>
>> --
>> Cormac Garvey
>> HPC Software Consultant
>> Scientific Computing
>> Idaho National Laboratory
>> Ph: 208-526-6294
>>
>>
>

Re: [petsc-users] Could not execute "['git', 'rev-parse', '--git-dir']"

[Kong, Fande]

Thanks, Cormac,

*module load git/1.8.5.2-GCC-4.8.3 *

works for me.

Did not try "module load git/2.16.2-GCCcore-5.4.0" yet.

I will try, and get it back here.



Fande

On Wed, Apr 4, 2018 at 4:39 PM, Garvey, Cormac T 
wrote:

>
> We needed to rebuilt git on the INL falcon cluster because github server
> changed such that it no longer accepted TLSv1.
>
> The default git on the falcon cluster /usr/bin/git is just a wrapper
> script, so users would not need to load any modules to
> use git.
>
> When you load load git on falcon1 or falcon2 does it still fail?
>
> module load git/2.16.2-GCCcore-5.4.0
>
> Thanks,
> Cormac.
>
>
>
> On Wed, Apr 4, 2018 at 4:28 PM, Kong, Fande  wrote:
>
>> Hi Cormac,
>>
>> Do you know anything on "git"? How did you guys build git on the
>> falcon1?  The default git on Falcon1 does not work with petsc any more.
>>
>>
>> Fande,
>>
>>
>>
>> On Wed, Apr 4, 2018 at 4:20 PM, Satish Balay  wrote:
>>
>>> Ok - I don't think I have access to this OS.
>>>
>>> And I see its from 2009 [sure its enterprise os - with regular backport
>>> updates]
>>>
>>> But its wierd that you have such a new version of git at /usr/bin/git
>>>
>>> From what we know so far - the problem appears to be some bad
>>> interaction of python-2.6 with this old OS [i.e old glibc etc..] - and
>>> this new git version [binary built locally or on a different OS and
>>> installed locally ?].
>>>
>>> Satish
>>>
>>> On Wed, 4 Apr 2018, Kong, Fande wrote:
>>>
>>> >  moose]$ uname -a
>>> > Linux falcon1 3.0.101-108.13-default #1 SMP Wed Oct 11 12:30:40 UTC
>>> 2017
>>> > (294ccfe) x86_64 x86_64 x86_64 GNU/Linux
>>> >
>>> >
>>> > moose]$ lsb_release -a
>>> > LSB Version:
>>> > core-2.0-noarch:core-3.2-noarch:core-4.0-noarch:core-2.0-x86
>>> _64:core-3.2-x86_64:core-4.0-x86_64:desktop-4.0-amd64:deskt
>>> op-4.0-noarch:graphics-2.0-amd64:graphics-2.0-noarch:graphic
>>> s-3.2-amd64:graphics-3.2-noarch:graphics-4.0-amd64:graphics-4.0-noarch
>>> > Distributor ID:SUSE LINUX
>>> > Description:SUSE Linux Enterprise Server 11 (x86_64)
>>> > Release:11
>>> > Codename:n/a
>>> >
>>> >
>>> >
>>> > On Wed, Apr 4, 2018 at 4:08 PM, Satish Balay 
>>> wrote:
>>> >
>>> > > On Wed, 4 Apr 2018, Satish Balay wrote:
>>> > >
>>> > > > On Wed, 4 Apr 2018, Satish Balay wrote:
>>> > > >
>>> > > > > was your '2.16.2' version installed from source?
>>> > > >
>>> > > > >>>
>>> > > > Checking for program /usr/bin/git...found
>>> > > > Defined make macro "GIT" to "git"
>>> > > > Executing: git --version
>>> > > > stdout: git version 2.16.2
>>> > > > 
>>> > > >
>>> > > > I gues its the OS default package
>>> > > >
>>> > > > >
>>> > > > Machine platform:
>>> > > > ('Linux', 'falcon1', '3.0.101-108.13-default', '#1 SMP Wed Oct 11
>>> > > 12:30:40 UTC 2017 (294ccfe)', 'x86_64', 'x86_64')
>>> > > > Python version:
>>> > > > 2.6.9 (unknown, Aug  5 2016, 11:15:31)
>>> > > > [GCC 4.3.4 [gcc-4_3-branch revision 152973]]
>>> > > > 
>>> > > >
>>> > > > What OS/version is on this machine? I can try reproducing in a VM
>>> > >
>>> > > It is strange that the kernel is old [3.0 - perhaps LTS OS] , python
>>> is
>>> > > old [2.6] - but git is new? [2.16?]
>>> > >
>>> > > https://urldefense.proofpoint.com/v2/url?u=https-3A__
>>> > > mirrors.edge.kernel.org_pub_software_scm_git_&d=DwIBAg&c=
>>> > > 54IZrppPQZKX9mLzcGdPfFD1hxrcB__aEkJFOKJFd00&r=DUUt3SRGI0_
>>> > > JgtNaS3udV68GRkgV4ts7XKfj2opmiCY&m=WF6ZxIh9Z9Hh2kYY0w70aNrgfPicp6
>>> > > kgIh5BvezPiEY&s=KWMsO7XC0-pQuQ_mD03tNJWEpxSTATlZW_DmX0QofGw&e=
>>> > > git-2.16.2.tar.gz  16-Feb-2018 17:48
>>> > > 7M
>>> > >
>>> > > Satish
>>> > >
>>> >
>>>
>>>
>>
>
>
> --
> Cormac Garvey
> HPC Software Consultant
> Scientific Computing
> Idaho National Laboratory
> Ph: 208-526-6294
>
>

Re: [petsc-users] Could not execute "['git', 'rev-parse', '--git-dir']"

[Garvey, Cormac T]

We needed to rebuilt git on the INL falcon cluster because github server
changed such that it no longer accepted TLSv1.

The default git on the falcon cluster /usr/bin/git is just a wrapper
script, so users would not need to load any modules to
use git.

When you load load git on falcon1 or falcon2 does it still fail?

module load git/2.16.2-GCCcore-5.4.0

Thanks,
Cormac.



On Wed, Apr 4, 2018 at 4:28 PM, Kong, Fande  wrote:

> Hi Cormac,
>
> Do you know anything on "git"? How did you guys build git on the falcon1?
> The default git on Falcon1 does not work with petsc any more.
>
>
> Fande,
>
>
>
> On Wed, Apr 4, 2018 at 4:20 PM, Satish Balay  wrote:
>
>> Ok - I don't think I have access to this OS.
>>
>> And I see its from 2009 [sure its enterprise os - with regular backport
>> updates]
>>
>> But its wierd that you have such a new version of git at /usr/bin/git
>>
>> From what we know so far - the problem appears to be some bad
>> interaction of python-2.6 with this old OS [i.e old glibc etc..] - and
>> this new git version [binary built locally or on a different OS and
>> installed locally ?].
>>
>> Satish
>>
>> On Wed, 4 Apr 2018, Kong, Fande wrote:
>>
>> >  moose]$ uname -a
>> > Linux falcon1 3.0.101-108.13-default #1 SMP Wed Oct 11 12:30:40 UTC 2017
>> > (294ccfe) x86_64 x86_64 x86_64 GNU/Linux
>> >
>> >
>> > moose]$ lsb_release -a
>> > LSB Version:
>> > core-2.0-noarch:core-3.2-noarch:core-4.0-noarch:core-2.0-
>> x86_64:core-3.2-x86_64:core-4.0-x86_64:desktop-4.0-amd64:des
>> ktop-4.0-noarch:graphics-2.0-amd64:graphics-2.0-noarch:grap
>> hics-3.2-amd64:graphics-3.2-noarch:graphics-4.0-amd64:graphics-4.0-noarch
>> > Distributor ID:SUSE LINUX
>> > Description:SUSE Linux Enterprise Server 11 (x86_64)
>> > Release:11
>> > Codename:n/a
>> >
>> >
>> >
>> > On Wed, Apr 4, 2018 at 4:08 PM, Satish Balay  wrote:
>> >
>> > > On Wed, 4 Apr 2018, Satish Balay wrote:
>> > >
>> > > > On Wed, 4 Apr 2018, Satish Balay wrote:
>> > > >
>> > > > > was your '2.16.2' version installed from source?
>> > > >
>> > > > >>>
>> > > > Checking for program /usr/bin/git...found
>> > > > Defined make macro "GIT" to "git"
>> > > > Executing: git --version
>> > > > stdout: git version 2.16.2
>> > > > 
>> > > >
>> > > > I gues its the OS default package
>> > > >
>> > > > >
>> > > > Machine platform:
>> > > > ('Linux', 'falcon1', '3.0.101-108.13-default', '#1 SMP Wed Oct 11
>> > > 12:30:40 UTC 2017 (294ccfe)', 'x86_64', 'x86_64')
>> > > > Python version:
>> > > > 2.6.9 (unknown, Aug  5 2016, 11:15:31)
>> > > > [GCC 4.3.4 [gcc-4_3-branch revision 152973]]
>> > > > 
>> > > >
>> > > > What OS/version is on this machine? I can try reproducing in a VM
>> > >
>> > > It is strange that the kernel is old [3.0 - perhaps LTS OS] , python
>> is
>> > > old [2.6] - but git is new? [2.16?]
>> > >
>> > > https://urldefense.proofpoint.com/v2/url?u=https-3A__
>> > > mirrors.edge.kernel.org_pub_software_scm_git_&d=DwIBAg&c=
>> > > 54IZrppPQZKX9mLzcGdPfFD1hxrcB__aEkJFOKJFd00&r=DUUt3SRGI0_
>> > > JgtNaS3udV68GRkgV4ts7XKfj2opmiCY&m=WF6ZxIh9Z9Hh2kYY0w70aNrgfPicp6
>> > > kgIh5BvezPiEY&s=KWMsO7XC0-pQuQ_mD03tNJWEpxSTATlZW_DmX0QofGw&e=
>> > > git-2.16.2.tar.gz  16-Feb-2018 17:48
>> > > 7M
>> > >
>> > > Satish
>> > >
>> >
>>
>>
>


-- 
Cormac Garvey
HPC Software Consultant
Scientific Computing
Idaho National Laboratory
Ph: 208-526-6294

Re: [petsc-users] Could not execute "['git', 'rev-parse', '--git-dir']"

[Kong, Fande]

Hi Cormac,

Do you know anything on "git"? How did you guys build git on the falcon1?
The default git on Falcon1 does not work with petsc any more.


Fande,



On Wed, Apr 4, 2018 at 4:20 PM, Satish Balay  wrote:

> Ok - I don't think I have access to this OS.
>
> And I see its from 2009 [sure its enterprise os - with regular backport
> updates]
>
> But its wierd that you have such a new version of git at /usr/bin/git
>
> From what we know so far - the problem appears to be some bad
> interaction of python-2.6 with this old OS [i.e old glibc etc..] - and
> this new git version [binary built locally or on a different OS and
> installed locally ?].
>
> Satish
>
> On Wed, 4 Apr 2018, Kong, Fande wrote:
>
> >  moose]$ uname -a
> > Linux falcon1 3.0.101-108.13-default #1 SMP Wed Oct 11 12:30:40 UTC 2017
> > (294ccfe) x86_64 x86_64 x86_64 GNU/Linux
> >
> >
> > moose]$ lsb_release -a
> > LSB Version:
> > core-2.0-noarch:core-3.2-noarch:core-4.0-noarch:core-2.
> 0-x86_64:core-3.2-x86_64:core-4.0-x86_64:desktop-4.0-amd64:
> desktop-4.0-noarch:graphics-2.0-amd64:graphics-2.0-noarch:
> graphics-3.2-amd64:graphics-3.2-noarch:graphics-4.0-amd64:
> graphics-4.0-noarch
> > Distributor ID:SUSE LINUX
> > Description:SUSE Linux Enterprise Server 11 (x86_64)
> > Release:11
> > Codename:n/a
> >
> >
> >
> > On Wed, Apr 4, 2018 at 4:08 PM, Satish Balay  wrote:
> >
> > > On Wed, 4 Apr 2018, Satish Balay wrote:
> > >
> > > > On Wed, 4 Apr 2018, Satish Balay wrote:
> > > >
> > > > > was your '2.16.2' version installed from source?
> > > >
> > > > >>>
> > > > Checking for program /usr/bin/git...found
> > > > Defined make macro "GIT" to "git"
> > > > Executing: git --version
> > > > stdout: git version 2.16.2
> > > > 
> > > >
> > > > I gues its the OS default package
> > > >
> > > > >
> > > > Machine platform:
> > > > ('Linux', 'falcon1', '3.0.101-108.13-default', '#1 SMP Wed Oct 11
> > > 12:30:40 UTC 2017 (294ccfe)', 'x86_64', 'x86_64')
> > > > Python version:
> > > > 2.6.9 (unknown, Aug  5 2016, 11:15:31)
> > > > [GCC 4.3.4 [gcc-4_3-branch revision 152973]]
> > > > 
> > > >
> > > > What OS/version is on this machine? I can try reproducing in a VM
> > >
> > > It is strange that the kernel is old [3.0 - perhaps LTS OS] , python is
> > > old [2.6] - but git is new? [2.16?]
> > >
> > > https://urldefense.proofpoint.com/v2/url?u=https-3A__
> > > mirrors.edge.kernel.org_pub_software_scm_git_&d=DwIBAg&c=
> > > 54IZrppPQZKX9mLzcGdPfFD1hxrcB__aEkJFOKJFd00&r=DUUt3SRGI0_
> > > JgtNaS3udV68GRkgV4ts7XKfj2opmiCY&m=WF6ZxIh9Z9Hh2kYY0w70aNrgfPicp6
> > > kgIh5BvezPiEY&s=KWMsO7XC0-pQuQ_mD03tNJWEpxSTATlZW_DmX0QofGw&e=
> > > git-2.16.2.tar.gz  16-Feb-2018 17:48
> > > 7M
> > >
> > > Satish
> > >
> >
>
>

Re: [petsc-users] Could not execute "['git', 'rev-parse', '--git-dir']"

[Satish Balay]

Ok - I don't think I have access to this OS.

And I see its from 2009 [sure its enterprise os - with regular backport updates]

But its wierd that you have such a new version of git at /usr/bin/git

>From what we know so far - the problem appears to be some bad
interaction of python-2.6 with this old OS [i.e old glibc etc..] - and
this new git version [binary built locally or on a different OS and installed 
locally ?].

Satish

On Wed, 4 Apr 2018, Kong, Fande wrote:

>  moose]$ uname -a
> Linux falcon1 3.0.101-108.13-default #1 SMP Wed Oct 11 12:30:40 UTC 2017
> (294ccfe) x86_64 x86_64 x86_64 GNU/Linux
> 
> 
> moose]$ lsb_release -a
> LSB Version:
> core-2.0-noarch:core-3.2-noarch:core-4.0-noarch:core-2.0-x86_64:core-3.2-x86_64:core-4.0-x86_64:desktop-4.0-amd64:desktop-4.0-noarch:graphics-2.0-amd64:graphics-2.0-noarch:graphics-3.2-amd64:graphics-3.2-noarch:graphics-4.0-amd64:graphics-4.0-noarch
> Distributor ID:SUSE LINUX
> Description:SUSE Linux Enterprise Server 11 (x86_64)
> Release:11
> Codename:n/a
> 
> 
> 
> On Wed, Apr 4, 2018 at 4:08 PM, Satish Balay  wrote:
> 
> > On Wed, 4 Apr 2018, Satish Balay wrote:
> >
> > > On Wed, 4 Apr 2018, Satish Balay wrote:
> > >
> > > > was your '2.16.2' version installed from source?
> > >
> > > >>>
> > > Checking for program /usr/bin/git...found
> > > Defined make macro "GIT" to "git"
> > > Executing: git --version
> > > stdout: git version 2.16.2
> > > 
> > >
> > > I gues its the OS default package
> > >
> > > >
> > > Machine platform:
> > > ('Linux', 'falcon1', '3.0.101-108.13-default', '#1 SMP Wed Oct 11
> > 12:30:40 UTC 2017 (294ccfe)', 'x86_64', 'x86_64')
> > > Python version:
> > > 2.6.9 (unknown, Aug  5 2016, 11:15:31)
> > > [GCC 4.3.4 [gcc-4_3-branch revision 152973]]
> > > 
> > >
> > > What OS/version is on this machine? I can try reproducing in a VM
> >
> > It is strange that the kernel is old [3.0 - perhaps LTS OS] , python is
> > old [2.6] - but git is new? [2.16?]
> >
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__
> > mirrors.edge.kernel.org_pub_software_scm_git_&d=DwIBAg&c=
> > 54IZrppPQZKX9mLzcGdPfFD1hxrcB__aEkJFOKJFd00&r=DUUt3SRGI0_
> > JgtNaS3udV68GRkgV4ts7XKfj2opmiCY&m=WF6ZxIh9Z9Hh2kYY0w70aNrgfPicp6
> > kgIh5BvezPiEY&s=KWMsO7XC0-pQuQ_mD03tNJWEpxSTATlZW_DmX0QofGw&e=
> > git-2.16.2.tar.gz  16-Feb-2018 17:48
> > 7M
> >
> > Satish
> >
> 

Re: [petsc-users] Could not execute "['git', 'rev-parse', '--git-dir']"

[Kong, Fande]

 moose]$ uname -a
Linux falcon1 3.0.101-108.13-default #1 SMP Wed Oct 11 12:30:40 UTC 2017
(294ccfe) x86_64 x86_64 x86_64 GNU/Linux


moose]$ lsb_release -a
LSB Version:
core-2.0-noarch:core-3.2-noarch:core-4.0-noarch:core-2.0-x86_64:core-3.2-x86_64:core-4.0-x86_64:desktop-4.0-amd64:desktop-4.0-noarch:graphics-2.0-amd64:graphics-2.0-noarch:graphics-3.2-amd64:graphics-3.2-noarch:graphics-4.0-amd64:graphics-4.0-noarch
Distributor ID:SUSE LINUX
Description:SUSE Linux Enterprise Server 11 (x86_64)
Release:11
Codename:n/a



On Wed, Apr 4, 2018 at 4:08 PM, Satish Balay  wrote:

> On Wed, 4 Apr 2018, Satish Balay wrote:
>
> > On Wed, 4 Apr 2018, Satish Balay wrote:
> >
> > > was your '2.16.2' version installed from source?
> >
> > >>>
> > Checking for program /usr/bin/git...found
> > Defined make macro "GIT" to "git"
> > Executing: git --version
> > stdout: git version 2.16.2
> > 
> >
> > I gues its the OS default package
> >
> > >
> > Machine platform:
> > ('Linux', 'falcon1', '3.0.101-108.13-default', '#1 SMP Wed Oct 11
> 12:30:40 UTC 2017 (294ccfe)', 'x86_64', 'x86_64')
> > Python version:
> > 2.6.9 (unknown, Aug  5 2016, 11:15:31)
> > [GCC 4.3.4 [gcc-4_3-branch revision 152973]]
> > 
> >
> > What OS/version is on this machine? I can try reproducing in a VM
>
> It is strange that the kernel is old [3.0 - perhaps LTS OS] , python is
> old [2.6] - but git is new? [2.16?]
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__
> mirrors.edge.kernel.org_pub_software_scm_git_&d=DwIBAg&c=
> 54IZrppPQZKX9mLzcGdPfFD1hxrcB__aEkJFOKJFd00&r=DUUt3SRGI0_
> JgtNaS3udV68GRkgV4ts7XKfj2opmiCY&m=WF6ZxIh9Z9Hh2kYY0w70aNrgfPicp6
> kgIh5BvezPiEY&s=KWMsO7XC0-pQuQ_mD03tNJWEpxSTATlZW_DmX0QofGw&e=
> git-2.16.2.tar.gz  16-Feb-2018 17:48
> 7M
>
> Satish
>

Re: [petsc-users] Could not execute "['git', 'rev-parse', '--git-dir']"

[Satish Balay]

On Wed, 4 Apr 2018, Satish Balay wrote:

> On Wed, 4 Apr 2018, Satish Balay wrote:
> 
> > was your '2.16.2' version installed from source?
> 
> >>>
> Checking for program /usr/bin/git...found
> Defined make macro "GIT" to "git"
> Executing: git --version
> stdout: git version 2.16.2
> 
> 
> I gues its the OS default package
> 
> >
> Machine platform:
> ('Linux', 'falcon1', '3.0.101-108.13-default', '#1 SMP Wed Oct 11 12:30:40 
> UTC 2017 (294ccfe)', 'x86_64', 'x86_64')
> Python version:
> 2.6.9 (unknown, Aug  5 2016, 11:15:31)
> [GCC 4.3.4 [gcc-4_3-branch revision 152973]]
> 
> 
> What OS/version is on this machine? I can try reproducing in a VM

It is strange that the kernel is old [3.0 - perhaps LTS OS] , python is old 
[2.6] - but git is new? [2.16?]

https://mirrors.edge.kernel.org/pub/software/scm/git/
git-2.16.2.tar.gz  16-Feb-2018 17:48  7M

Satish

Re: [petsc-users] Could not execute "['git', 'rev-parse', '--git-dir']"

[Satish Balay]

On Wed, 4 Apr 2018, Satish Balay wrote:

> was your '2.16.2' version installed from source?

>>>
Checking for program /usr/bin/git...found
Defined make macro "GIT" to "git"
Executing: git --version
stdout: git version 2.16.2


I gues its the OS default package

>
Machine platform:
('Linux', 'falcon1', '3.0.101-108.13-default', '#1 SMP Wed Oct 11 12:30:40 UTC 
2017 (294ccfe)', 'x86_64', 'x86_64')
Python version:
2.6.9 (unknown, Aug  5 2016, 11:15:31)
[GCC 4.3.4 [gcc-4_3-branch revision 152973]]


What OS/version is on this machine? I can try reproducing in a VM

Satish

Re: [petsc-users] Could not execute "['git', 'rev-parse', '--git-dir']"

[Satish Balay]

[balay@fedora ~]$ cat /etc/fedora-release 
Fedora release 27 (Twenty Seven)
[balay@fedora ~]$ git --version
git version 2.14.3
[balay@fedora ~]$ 


balay@asterix /home/balay
$ cat /etc/fedora-release 
Fedora release 28 (Twenty Eight)
balay@asterix /home/balay
$ git --version
git version 2.17.0.rc2
balay@asterix /home/balay


The first one is a nightlybuild testbox - and the second one is my
laptop - and I haven't seen this issue with either of them. [or any of
our other nightlybuilds - or a bugreport form any other user]

was your '2.16.2' version installed from source?

Satish

On Wed, 4 Apr 2018, Kong, Fande wrote:

> Updated:
> 
> If switch to a different version of git. The configuration is going to
> work.
> 
> 
> This one works:
> 
> 
> * petsc]$ git --version git version 1.8.5.2*
> 
> 
> This new version does not work:
> 
>  petsc]$ git --version
> git version 2.16.2
> 
> 
> 
> Fande.
> 
> 
> On Wed, Mar 7, 2018 at 2:56 PM, Satish Balay  wrote:
> 
> > On Wed, 7 Mar 2018, Kong, Fande wrote:
> >
> > > > I meant just the 3 lines - not the whole function.
> > >
> > > I knew this. "3 lines" does not work at all.
> > >
> > > I forgot the error message.
> >
> > Then you are likely to use the wrong [git] snapshot - and not the
> > snapshot listed by self.gitcommit - for that package.
> >
> > Satish
> >
> 

Re: [petsc-users] Could not execute "['git', 'rev-parse', '--git-dir']"

[Kong, Fande]

On Wed, Apr 4, 2018 at 3:55 PM, Jed Brown  wrote:

> "Kong, Fande"  writes:
>
> > Updated:
> >
> > If switch to a different version of git. The configuration is going to
> > work.
> >
> >
> > This one works:
> >
> >
> > * petsc]$ git --version git version 1.8.5.2*
> >
> >
> > This new version does not work:
> >
> >  petsc]$ git --version
> > git version 2.16.2
>
> Can you reproduce the error in your terminal or does it only happen
> through configure?
>

It only happens using configure.

Fande,

Re: [petsc-users] Could not execute "['git', 'rev-parse', '--git-dir']"

[Jed Brown]

"Kong, Fande"  writes:

> Updated:
>
> If switch to a different version of git. The configuration is going to
> work.
>
>
> This one works:
>
>
> * petsc]$ git --version git version 1.8.5.2*
>
>
> This new version does not work:
>
>  petsc]$ git --version
> git version 2.16.2

Can you reproduce the error in your terminal or does it only happen through 
configure?

Re: [petsc-users] Could not execute "['git', 'rev-parse', '--git-dir']"

[Kong, Fande]

Updated:

If switch to a different version of git. The configuration is going to
work.


This one works:


* petsc]$ git --version git version 1.8.5.2*


This new version does not work:

 petsc]$ git --version
git version 2.16.2



Fande.


On Wed, Mar 7, 2018 at 2:56 PM, Satish Balay  wrote:

> On Wed, 7 Mar 2018, Kong, Fande wrote:
>
> > > I meant just the 3 lines - not the whole function.
> >
> > I knew this. "3 lines" does not work at all.
> >
> > I forgot the error message.
>
> Then you are likely to use the wrong [git] snapshot - and not the
> snapshot listed by self.gitcommit - for that package.
>
> Satish
>

Re: [petsc-users] using hypre's GPU feature through PETSc

[Smith, Barry F.]

   Our config/BuildSystem/config/packages/hypre.py does not yet have code to 
communicate GPU information for building hypre. One would need to go through 
the hypre install documentation to determine the hypre configure flags for 
enabling the GPU and add support to hypre.py for passing these flags to hypre 
configure.

   Barry

An example of the type of flag needed can be found in superlu_dist.py 

help.addArgument('SUPERLU_DIST', '-download-superlu_dist-gpu=',
nargs.ArgBool(None, 0, 'Install Superlu_DIST to use GPUs'))



> On Apr 3, 2018, at 7:24 PM, Xiangdong  wrote:
> 
> Hello everyone,
> 
> The latest Hypre has GPU capability. Can I use hypre GPU feature through 
> PETSc? If it is possible, what configuration changes should I make in PETSc?
> 
> Thank you.
> 
> Best,
> Xiangdong
> 
> 

Re: [petsc-users] using hypre's GPU feature through PETSc

[Mark Adams]

On Tue, Apr 3, 2018 at 9:24 PM, Xiangdong  wrote:

> Hello everyone,
>
> The latest Hypre has GPU capability. Can I use hypre GPU feature through
> PETSc? If it is possible, what configuration changes should I make in PETSc?
>

It should work. I don't if anyone has used it yet. We recently verified
that the OpenMP in hypre works.


>
> Thank you.
>
> Best,
> Xiangdong
>
>
>

Re: [petsc-users] DMForestTransferVec with -petscspace_order 0

[Yann Jobic]

Hi Isaac,

It's working !!

Many thanks !

Regards,

Yann


Le 04/04/2018 à 15:18, Tobin Isaac a écrit :

Hi Yann,

On Tue, Apr 03, 2018 at 05:29:39PM +0200, Yann Jobic wrote:

Hi,

Thanks for the fast answer ! And sorry for my late one...
As a test, i'm using ex2.c in test/forest directory.

I'm using 2 git depot (master), one from this week end, and one of today. I
see some different behaviors.

For the git from the week end : v3.8.4-1-g756c7f9
In 2D, everything is ok (petscspace_order = 0,1,2) : mpiexec -n 1 ./ex2
-petscspace_poly_tensor -petscspace_order 2 -dim 2
In 3D, only -petscspace_order 2 works. For the other ones, i put the full
message in a log file.

This looks like a version of petsc/maint commit.  I have not tried to
fix this (a new maintenance release is imminent).


For the git from today : v3.8.4-2420-g8f4cb0b
In 2D, petscspace_order is ok for 2 and 1, but do not work for 0.
In 3D, same as 2D, it's working for petscspace_order 2 and 1, but not for 0.
(see log file)
Many thanks for the help !

I have fixed this in the branch `tisaac/fix-height-ds` on the repo.
It does not require any interface changes, so as soon as it is
approved, it will be integrated into the master branch and
to-be-released maintained version v3.8.9.

Cheers,
   Toby


Regards,

Yann


Le 03/04/2018 à 03:33, Tobin Isaac a écrit :

Hi Yann,

Thanks for pointing this out to us.  Matt and I are the two most
actively developing in this area.  We have been working on separate
threads and this looks like an issue where we need to sync up.  I
think there is a simple fix, but it would be helpful to know which
version petsc you're working from: I'm seeing different
behavior.  Could you please send along more complete output?

Cheers,
Toby

On Mon, Apr 02, 2018 at 04:42:29PM +0200, yann JOBIC wrote:

Hi,

I'm using DMForestTransferVec, as in "dm/impls/forest/examples/tests/ex2.c".

I would like to use it with a space approximation order at zero
(-petscspace_order 0). However, in this case, it's not working (valgrind
output of ex2.c from forest test) :

==8604== Conditional jump or move depends on uninitialised value(s)
==8604==    at 0x47D74F: DMPlexVecGetClosure (plex.c:4035)
==8604==    by 0x557612: DMPlexLocatePoint_General_3D_Internal
(plexgeometry.c:153)
==8604==    by 0x559B85: DMPlexLocatePoint_Internal (plexgeometry.c:383)
==8604==    by 0x611EED: DMPlexComputeInjectorReferenceTree
(plextree.c:3247)
==8604==    by 0x6148DB: DMPlexReferenceTreeGetInjector (plextree.c:3454)
==8604==    by 0x61EAD8: DMPlexTransferVecTree_Inject (plextree.c:4319)
==8604==    by 0x620CC1: DMPlexTransferVecTree (plextree.c:4527)
==8604==    by 0x7F23D8: DMForestTransferVec_p8est (pforest.c:4239)
==8604==    by 0x429B48: DMForestTransferVec (forest.c:985)
==8604==    by 0x40BB8A: main (transf_test.c:136)

With the error message :

[0]PETSC ERROR: Caught signal number 11 SEGV: Segmentation Violation,
probably memory access out of range

It's working fine in 2D (p4est). The problem arise in 3D (p8est).

Is it an expected behavior ? Am i doing something wrong ?

Thanks in advance,

Yann


--
___

Yann JOBIC
HPC engineer
IUSTI-CNRS UMR 7343 - Polytech Marseille
Technopôle de Château Gombert
5 rue Enrico Fermi
13453 Marseille cedex 13
Tel : (33) 4 91 10 69 43
Fax : (33) 4 91 10 69 69



---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus
yann@crabe:~/projet/AMR/moulinette$ mpiexec -n 1 ./ex2 -petscspace_poly_tensor 
-petscspace_order 0 -dim 3
[0]PETSC ERROR: 

[0]PETSC ERROR: Caught signal number 11 SEGV: Segmentation Violation, probably 
memory access out of range
[0]PETSC ERROR: Try option -start_in_debugger or -on_error_attach_debugger
[0]PETSC ERROR: or see 
http://www.mcs.anl.gov/petsc/documentation/faq.html#valgrind
[0]PETSC ERROR: or try http://valgrind.org on GNU/linux and Apple Mac OS X to 
find memory corruption errors
[0]PETSC ERROR: likely location of problem given in stack below
[0]PETSC ERROR: -  Stack Frames 

[0]PETSC ERROR: Note: The EXACT line numbers in the stack are not available,
[0]PETSC ERROR:   INSTEAD the line number of the start of the function
[0]PETSC ERROR:   is given.
[0]PETSC ERROR: [0] DMPlexVecGetClosure line 4020 
/home/yann/src/petsc-git/src/dm/impls/plex/plex.c
[0]PETSC ERROR: [0] DMPlexLocatePoint_General_3D_Internal line 150 
/home/yann/src/petsc-git/src/dm/impls/plex/plexgeometry.c
[0]PETSC ERROR: [0] DMPlexLocatePoint_Internal line 361 
/home/yann/src/petsc-git/src/dm/impls/plex/plexgeometry.c
[0]PETSC ERROR: [0] DMPlexComputeInjectorReferenceTree line 3008 
/home/yann/src/petsc-git/src/dm/impls/plex/plextree.c
[0]PETSC ERROR: [0] DMPlexReferenceTreeGetInjector line 3449 
/home/yann/src/petsc-git/src/dm/impls/plex/plextree.c
[0]PETSC ERROR: [0] DMPlexTransferVecTree_I

Re: [petsc-users] DMForestTransferVec with -petscspace_order 0

[Tobin Isaac]

Hi Yann,

On Tue, Apr 03, 2018 at 05:29:39PM +0200, Yann Jobic wrote:
> Hi,
> 
> Thanks for the fast answer ! And sorry for my late one...
> As a test, i'm using ex2.c in test/forest directory.
> 
> I'm using 2 git depot (master), one from this week end, and one of today. I
> see some different behaviors.
> 
> For the git from the week end : v3.8.4-1-g756c7f9
> In 2D, everything is ok (petscspace_order = 0,1,2) : mpiexec -n 1 ./ex2
> -petscspace_poly_tensor -petscspace_order 2 -dim 2
> In 3D, only -petscspace_order 2 works. For the other ones, i put the full
> message in a log file.

This looks like a version of petsc/maint commit.  I have not tried to
fix this (a new maintenance release is imminent).

> 
> For the git from today : v3.8.4-2420-g8f4cb0b
> In 2D, petscspace_order is ok for 2 and 1, but do not work for 0.
> In 3D, same as 2D, it's working for petscspace_order 2 and 1, but not for 0.
> (see log file)
> Many thanks for the help !

I have fixed this in the branch `tisaac/fix-height-ds` on the repo.
It does not require any interface changes, so as soon as it is
approved, it will be integrated into the master branch and
to-be-released maintained version v3.8.9.

Cheers,
  Toby

> 
> Regards,
> 
> Yann
> 
> 
> Le 03/04/2018 à 03:33, Tobin Isaac a écrit :
> > Hi Yann,
> > 
> > Thanks for pointing this out to us.  Matt and I are the two most
> > actively developing in this area.  We have been working on separate
> > threads and this looks like an issue where we need to sync up.  I
> > think there is a simple fix, but it would be helpful to know which
> > version petsc you're working from: I'm seeing different
> > behavior.  Could you please send along more complete output?
> > 
> > Cheers,
> >Toby
> > 
> > On Mon, Apr 02, 2018 at 04:42:29PM +0200, yann JOBIC wrote:
> > > Hi,
> > > 
> > > I'm using DMForestTransferVec, as in 
> > > "dm/impls/forest/examples/tests/ex2.c".
> > > 
> > > I would like to use it with a space approximation order at zero
> > > (-petscspace_order 0). However, in this case, it's not working (valgrind
> > > output of ex2.c from forest test) :
> > > 
> > > ==8604== Conditional jump or move depends on uninitialised value(s)
> > > ==8604==    at 0x47D74F: DMPlexVecGetClosure (plex.c:4035)
> > > ==8604==    by 0x557612: DMPlexLocatePoint_General_3D_Internal
> > > (plexgeometry.c:153)
> > > ==8604==    by 0x559B85: DMPlexLocatePoint_Internal (plexgeometry.c:383)
> > > ==8604==    by 0x611EED: DMPlexComputeInjectorReferenceTree
> > > (plextree.c:3247)
> > > ==8604==    by 0x6148DB: DMPlexReferenceTreeGetInjector (plextree.c:3454)
> > > ==8604==    by 0x61EAD8: DMPlexTransferVecTree_Inject (plextree.c:4319)
> > > ==8604==    by 0x620CC1: DMPlexTransferVecTree (plextree.c:4527)
> > > ==8604==    by 0x7F23D8: DMForestTransferVec_p8est (pforest.c:4239)
> > > ==8604==    by 0x429B48: DMForestTransferVec (forest.c:985)
> > > ==8604==    by 0x40BB8A: main (transf_test.c:136)
> > > 
> > > With the error message :
> > > 
> > > [0]PETSC ERROR: Caught signal number 11 SEGV: Segmentation Violation,
> > > probably memory access out of range
> > > 
> > > It's working fine in 2D (p4est). The problem arise in 3D (p8est).
> > > 
> > > Is it an expected behavior ? Am i doing something wrong ?
> > > 
> > > Thanks in advance,
> > > 
> > > Yann
> > > 
> 
> -- 
> ___
> 
> Yann JOBIC
> HPC engineer
> IUSTI-CNRS UMR 7343 - Polytech Marseille
> Technopôle de Château Gombert
> 5 rue Enrico Fermi
> 13453 Marseille cedex 13
> Tel : (33) 4 91 10 69 43
> Fax : (33) 4 91 10 69 69
> 
> 
> 
> ---
> L'absence de virus dans ce courrier électronique a été vérifiée par le 
> logiciel antivirus Avast.
> https://www.avast.com/antivirus

> yann@crabe:~/projet/AMR/moulinette$ mpiexec -n 1 ./ex2 
> -petscspace_poly_tensor -petscspace_order 0 -dim 3
> [0]PETSC ERROR: 
> 
> [0]PETSC ERROR: Caught signal number 11 SEGV: Segmentation Violation, 
> probably memory access out of range
> [0]PETSC ERROR: Try option -start_in_debugger or -on_error_attach_debugger
> [0]PETSC ERROR: or see 
> http://www.mcs.anl.gov/petsc/documentation/faq.html#valgrind
> [0]PETSC ERROR: or try http://valgrind.org on GNU/linux and Apple Mac OS X to 
> find memory corruption errors
> [0]PETSC ERROR: likely location of problem given in stack below
> [0]PETSC ERROR: -  Stack Frames 
> 
> [0]PETSC ERROR: Note: The EXACT line numbers in the stack are not available,
> [0]PETSC ERROR:   INSTEAD the line number of the start of the function
> [0]PETSC ERROR:   is given.
> [0]PETSC ERROR: [0] DMPlexVecGetClosure line 4020 
> /home/yann/src/petsc-git/src/dm/impls/plex/plex.c
> [0]PETSC ERROR: [0] DMPlexLocatePoint_General_3D_Internal line 150 
> /home/yann/src/petsc-git/src/dm/impls/plex/plexgeometry.c
> [0]PETSC ERROR: [0] DMPlexLocatePoint_Internal line 361 
> /home/yann/src/petsc-git/src/dm/impls/ple

Re: [petsc-users] Obtaining compiling and building information from a.out

[Matthew Knepley]

On Thu, Mar 29, 2018 at 1:48 AM, TAY wee-beng  wrote:

>
> On 28/3/2018 5:45 PM, Matthew Knepley wrote:
>
> On Tue, Mar 27, 2018 at 10:17 PM, TAY wee-beng  wrote:
>
>> Hi Dave,
>>
>> I looked at the output using log_view and re-compile. However, although I
>> use the same options "-xHost -g -O3 -openmp" (some filenames and dir names
>> are now different but they are actually the same), I still get different
>> results timing. I have attach both, fast and slow. So what else can I do to
>> pinpoint the differences?
>>
> The solver options must be different. In Fast, there is almost no time in
> LUFactor, but in Slow its half the time.
>
>Matt
>
> Hi Matt,
>
> Finally found that it was because I was using KSPRICHARDSON in the new
> code. KSPGMRES in the old code is much faster.
>
> I also tried cg, lsqr, fgmres. CG and GMRES seem similar in term of best
> performance. Are there any other recommendations to try? The Poisson eqn is
> symmetric.
>

Krylov solvers fundamentally do not matter for solving elliptic problems.
It comes down to your preconditioner.


> I also tried -pc_type mg -pc_mg_nlevels 2 instead of -poisson_pc_type gamg
> -poisson_pc_gamg_agg_nsmooths 1.
>
> It reduces the runtime from 2.25 to 1.46min.
>

Yes, GMG has faster setup time than AMG. The solve time should be similar.


> However, I found that my subroutine is very similar to my momentum
> subroutine, which is based on KSPSolve:
>
> 0. DMDACreate, DMDACreate3d etc
> 1. Assemble matrix
> 2. KSPSetOperators, KSPSetType etc
> 3. KSPSolve
>
> However, the 2D Poisson example in ex5f.F90 uses SNESSetDM, SNESSolve etc.
> So does it matter if I use SNESSolve or KSPSolve if I'm using -pc_type mg?
>

Not really.

  Thanks,

 Matt


> Thank you very much.
>>
>> Yours sincerely,
>>
>> 
>> TAY Wee-Beng (Zheng Weiming) 郑伟明
>> Personal research webpage: http://tayweebeng.wixsite.com/website
>> Youtube research showcase: 
>> https://www.youtube.com/channel/UC72ZHtvQNMpNs2uRTSToiLA
>> linkedin: www.linkedin.com/in/tay-weebeng
>> 
>>
>> On 27/3/2018 5:22 PM, Dave May wrote:
>>
>>
>>
>> On 27 March 2018 at 10:16, TAY wee-beng  wrote:
>>
>>> Hi,
>>>
>>> I have been compiling and building different version of my CFD with the
>>> intel 2016, 2018 compilers, and also different compiling options.
>>>
>>> I tested a version of my a.out and it is much faster than the other
>>> a.out, using only 3 min instead of more than 10min to solve a certain case
>>> using GAMG.
>>>
>>> However, I can't recall how it was compiled. I only know that I used the
>>> intel 2016 compiler.
>>>
>>> So is there any way I can find out how the a.out was compiled? Like what
>>> options were used?
>>
>>
>> Since you posted to the list I presume "a.out" links against petsc...
>> If so, run your code with
>>   -log_view
>>
>> Upon calling PetscFinalize(), you will get all the options given to PETSc
>> configure, plus the CFLAGS, link lines, etc.
>>
>>
>>
>
>
> --
> 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-users] Obtaining compiling and building information from a.out

[TAY wee-beng]

Hi,

I emailed as shown below a while ago but I have yet to get a response. 
Can someone help?


Thank you very much.

Yours sincerely,


TAY Wee-Beng (Zheng Weiming) 郑伟明
Personal research webpage: http://tayweebeng.wixsite.com/website
Youtube research showcase: 
https://www.youtube.com/channel/UC72ZHtvQNMpNs2uRTSToiLA
linkedin: www.linkedin.com/in/tay-weebeng


On 29/3/2018 1:48 PM, TAY wee-beng wrote:


On 28/3/2018 5:45 PM, Matthew Knepley wrote:
On Tue, Mar 27, 2018 at 10:17 PM, TAY wee-beng > wrote:


Hi Dave,

I looked at the output using log_view and re-compile. However,
although I use the same options "-xHost -g -O3 -openmp" (some
filenames and dir names are now different but they are actually
the same), I still get different results timing. I have attach
both, fast and slow. So what else can I do to pinpoint the
differences?

The solver options must be different. In Fast, there is almost no 
time in LUFactor, but in Slow its half the time.


   Matt

Hi Matt,

Finally found that it was because I was using KSPRICHARDSON in the new 
code. KSPGMRES in the old code is much faster.


I also tried cg, lsqr, fgmres. CG and GMRES seem similar in term of 
best performance. Are there any other recommendations to try? The 
Poisson eqn is symmetric.


I also tried -pc_type mg -pc_mg_nlevels 2 instead of -poisson_pc_type 
gamg -poisson_pc_gamg_agg_nsmooths 1.


It reduces the runtime from 2.25 to 1.46min.

However, I found that my subroutine is very similar to my momentum 
subroutine, which is based on KSPSolve:


0. DMDACreate, DMDACreate3d etc
1. Assemble matrix
2. KSPSetOperators, KSPSetType etc
3. KSPSolve

However, the 2D Poisson example in ex5f.F90 uses SNESSetDM, SNESSolve 
etc. So does it matter if I use SNESSolve or KSPSolve if I'm using 
-pc_type mg?



Thank you very much.

Yours sincerely,


TAY Wee-Beng (Zheng Weiming) 郑伟明
Personal research webpage:http://tayweebeng.wixsite.com/website

Youtube research 
showcase:https://www.youtube.com/channel/UC72ZHtvQNMpNs2uRTSToiLA

linkedin:www.linkedin.com/in/tay-weebeng



On 27/3/2018 5:22 PM, Dave May wrote:



On 27 March 2018 at 10:16, TAY wee-beng mailto:zon...@gmail.com>> wrote:

Hi,

I have been compiling and building different version of my
CFD with the intel 2016, 2018 compilers, and also different
compiling options.

I tested a version of my a.out and it is much faster than
the other a.out, using only 3 min instead of more than 10min
to solve a certain case using GAMG.

However, I can't recall how it was compiled. I only know
that I used the intel 2016 compiler.

So is there any way I can find out how the a.out was
compiled? Like what options were used?


Since you posted to the list I presume "a.out" links against
petsc...
If so, run your code with
  -log_view

Upon calling PetscFinalize(), you will get all the options given
to PETSc configure, plus the CFLAGS, link lines, etc.






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