On Thu, 25 Dec 2014, Matthew Knepley wrote:
> On Thu, Dec 25, 2014 at 12:35 PM, Satish Balay wrote:
>
> > On Wed, 24 Dec 2014, Matthew Knepley wrote:
> >
> > > On Wed, Dec 24, 2014 at 3:48 PM, Jed Brown wrote:
> > >
> > > > Barry Smith writes:
> > > >
> > > > >> On Dec 24, 2014, at 12:26 PM, J
On Thu, Dec 25, 2014 at 12:35 PM, Satish Balay wrote:
> On Wed, 24 Dec 2014, Matthew Knepley wrote:
>
> > On Wed, Dec 24, 2014 at 3:48 PM, Jed Brown wrote:
> >
> > > Barry Smith writes:
> > >
> > > >> On Dec 24, 2014, at 12:26 PM, Jed Brown wrote:
> > > >>
> > > >> In this case, it might be mo
On Wed, 24 Dec 2014, Matthew Knepley wrote:
> On Wed, Dec 24, 2014 at 3:48 PM, Jed Brown wrote:
>
> > Barry Smith writes:
> >
> > >> On Dec 24, 2014, at 12:26 PM, Jed Brown wrote:
> > >>
> > >> In this case, it might be more reliable to compare "cc --version".
> > >
> > > Presumably this is
On Wed, Dec 24, 2014 at 3:48 PM, Jed Brown wrote:
> Barry Smith writes:
>
> >> On Dec 24, 2014, at 12:26 PM, Jed Brown wrote:
> >>
> >> In this case, it might be more reliable to compare "cc --version".
> >
> > Presumably this is trivial with the gnumake stuff?
>
> It's easy to run it and com
Barry Smith writes:
> Plenty of things are desirable, some are even achievable, but even fewer
> are worth doing.
Well, this sort of checking is what we're talking about because it costs
a lot of human time (both users and developers/support). I proposed an
organization that would allow arbi
Plenty of things are desirable, some are even achievable, but even fewer are
worth doing.
> On Dec 24, 2014, at 3:48 PM, Jed Brown wrote:
>
> Barry Smith writes:
>
>>> On Dec 24, 2014, at 12:26 PM, Jed Brown wrote:
>>>
>>> In this case, it might be more reliable to compare "cc --version"
Barry Smith writes:
>> On Dec 24, 2014, at 12:26 PM, Jed Brown wrote:
>>
>> In this case, it might be more reliable to compare "cc --version".
>
> Presumably this is trivial with the gnumake stuff?
It's easy to run it and compare before proceeding with the build.
> And the mythical petsc
> On Dec 24, 2014, at 12:26 PM, Jed Brown wrote:
>
>>
>
>
> In this case, it might be more reliable to compare "cc --version".
Presumably this is trivial with the gnumake stuff?
And the mythical petsc-config could do any number of sanity checks each time
it is run.
Barry
> Module
Barry Smith writes:
> Now change the compiler to something else from Cray and run again.
Starting with PrgEnv-gnu:
jedbrow@edison01:~> env | grep MODULE > PrgEnv-gnu.txt
jedbrow@edison01:~> module swap PrgEnv-{gnu,cray}
jedbrow@edison01:~> env | grep MODULE > PrgEnv-cray.txt
jedbrow@e
Now change the compiler to something else from Cray and run again.
> On Dec 24, 2014, at 12:56 AM, Satish Balay wrote:
>
> wrt cray modules - I see the following env variables set [with a 'MODULE' in
> the env variable name]
>
> Satish
>
> ---
> balay@hopper01:~> env |grep MODULE
> MOD
wrt cray modules - I see the following env variables set [with a 'MODULE' in
the env variable name]
Satish
---
balay@hopper01:~> env |grep MODULE
MODULE_VERSION_STACK=3.2.6.7
LIBRARYMODULES=acml:alps:apprentice2:atp:cray-fftw:cray-libsci:cray-mpich2:cray-petsc:cray-petsc-complex:cray-shmem:c
I couldn't find any environmental variables for softenv and haven't logged
into a cray in decades. We don't have to abort for all changes but perhaps
could produce warning text or detect serious changes?
Barry
> On Dec 23, 2014, at 9:31 PM, Jed Brown wrote:
>
> Barry Smith writes:
>
>>
Barry Smith writes:
> Redirecting Jed's question specifically for PETSc configure.
>
> Can we/should we save the modules setting at configure time and then
> check them always at make time? Is some environmental variable set
> that has a unique value based on the modules loaded?
We can d
Redirecting Jed's question specifically for PETSc configure.
Can we/should we save the modules setting at configure time and then check
them always at make time? Is some environmental variable set that has a unique
value based on the modules loaded?
If this is a common problem for us th
14 matches
Mail list logo
