The Institute of Arctic and Alpine Research (INSTAAR) and Community
Surface Dynamics Modeling System (CSDMS) at the University of Colorado
invite applications for a tenure-track assistant professor position in
Computational Earth-Surface Process Modeling, with an August 2019
start. CSDMS is an
Satish,
My problem is that my application links with PETSc and another library
(Iphreeqc) that uses libstdc++. I compiled this other library with a
newer gcc (6.1). Then, during the configuration of my application (with
CMake) it looks into petscvariables to get the additional libraries
BTW: You have not stated what problem you are encountering due to this
reference to old gcc libraries from ifort.
Satish
On Tue, 23 Oct 2018, Balay, Satish wrote:
> You can check 'ifort -v test.F' - to see how its using gcc internally.
>
> configure.log will have the details on where the path
You can check 'ifort -v test.F' - to see how its using gcc internally.
configure.log will have the details on where the path is coming from. [you can
send us this log]
PETSc configure attempts to determine the compiler libraries - and this part
could show
up with some paths that are not
Thank you Satish for your response,
Yes I am intended to use ifort with gcc.
I changed ifort versions to one that does not include tbb.
However, PETSc is still including
-L/usr/lib/gcc/x86_64-redhat-linux/4.1.2 in petscvariables, attached you
will find an updated petscvariables file.
ifort
Yeah, I don't think there is anything wrong with checking
INTEL_MKL_VERSION for this purpose.
"Balay, Satish" writes:
> On Tue, 23 Oct 2018, Mills, Richard Tran wrote:
>
>> On 10/23/18 2:31 PM, Matthew Knepley wrote:
>> On Tue, Oct 23, 2018 at 2:20 PM Mills, Richard Tran
>>
On Tue, 23 Oct 2018, Mills, Richard Tran wrote:
> On 10/23/18 2:31 PM, Matthew Knepley wrote:
> On Tue, Oct 23, 2018 at 2:20 PM Mills, Richard Tran
> mailto:rtmi...@anl.gov>> wrote:
> Barry, Satish, and others,
>
> In MKL 2018 update 2, the old, non-inspector executor sparse BLAS interfaces
>
On 10/23/18 2:31 PM, Matthew Knepley wrote:
On Tue, Oct 23, 2018 at 2:20 PM Mills, Richard Tran
mailto:rtmi...@anl.gov>> wrote:
Barry, Satish, and others,
In MKL 2018 update 2, the old, non-inspector executor sparse BLAS interfaces
were deprecated in favor of the newer, inspector-executor
On Tue, Oct 23, 2018 at 2:20 PM Mills, Richard Tran wrote:
> Barry, Satish, and others,
>
> In MKL 2018 update 2, the old, non-inspector executor sparse BLAS
> interfaces were deprecated in favor of the newer, inspector-executor
> versions. To keep lots of warnings from being generated, I put in
Barry, Satish, and others,
In MKL 2018 update 2, the old, non-inspector executor sparse BLAS interfaces
were deprecated in favor of the newer, inspector-executor versions. To keep
lots of warnings from being generated, I put in some preprocessor code to avoid
using these interfaces in AIJMKL,
Hi,
some more information on this topic.
First, Adrians code is not wrong. The statement on the IBM homepage
regarding type(*) and type-bound procedures is according to my current
understanding simply not true.
However, type(*) is a feature of Fortran 2018, a standard that is not
even published.
In the first paragraph, with the list of characteristics that should not
trigger harassment, suggest to add "native language" or similar, to
underscore the point that, while the working language is English, the
important things are the ideas, not the particulars of usage.
Am Di., 23. Okt. 2018 um
Dear PETSc folks,
I ask all members of the PETSc team to review the following proposal for
adopting a code of conduct:
https://bitbucket.org/petsc/petsc/pull-requests/1196/code-of-conduct-adopt-contributor-covenant/diff
If you have questions, concerns, etc., please reply to this email
13 matches
Mail list logo
