Thanks, you were right, I needed to check the paths and my .py files. Now
./configure runs perfect and the variable PETSC_HAVE_PACKAGE is set to 1. The
only thing is that during compilation my folder cpardiso/cpardiso.c is not
listed so I'm not sure if my code was compiled. So I'don't know if t
Jed did not like the _ in it. I liked it :-(
On Sep 12, 2013, at 5:19 PM, "Mark F. Adams" wrote:
> And there is already:
>
> PETSC_DEPRECATED("Use PCMGResidualDefault()") PETSC_STATIC_INLINE
> PetscErrorCode PCMGResidual_Default(Mat A,Vec b,Vec x,Vec r) {
> return PCMGResidualDefault(A,b,x
No system is perfect. I was just pointing out that the model we selected was
dictated by one particularly bad fortran compiler design decision and
atheistically I don't like it. I was not proposing a change.
On Sep 12, 2013, at 6:39 PM, Jed Brown wrote:
> Barry Smith writes:
>
>> My solu
Barry Smith writes:
> My solution was that the those "defaults" would not be in the public
> interface :-)
Fine, get rid of all of these:
$ git grep '[a-z]Default(' include/*.h
include/
My solution was that the those "defaults" would not be in the public
interface :-)
I know, I know you have some reason to have them be in the public interface.
But it is not a good enough reason to have function names that are not
"natural" :-)
On Sep 12, 2013, at 6:30 PM, Jed Brown w
Barry Smith writes:
> Jed did not like the _ in it. I liked it :-(
I suppose you love PETSC_HAVE_FORTRAN_UNDERSCORE_UNDERSCORE as well?
http://mail-archive.com/search?l=mid&q=87ehby8it6@mcs.anl.gov
PETSc's public interface currently avoids underscores in the public
interface. Since we put
And there is already:
PETSC_DEPRECATED("Use PCMGResidualDefault()") PETSC_STATIC_INLINE
PetscErrorCode PCMGResidual_Default(Mat A,Vec b,Vec x,Vec r) {
return PCMGResidualDefault(A,b,x,r);
}
Should I assume PCMGResidualDefault is dead and change this to:
PETSC_DEPRECATED("Use MatResidualDefaul
On Sep 12, 2013, at 4:39 PM, "Mark F. Adams" wrote:
> I'm not sure what to do with:
>
> PetscErrorCode PCMGSetResidual(PC pc,PetscInt l,PetscErrorCode
> (*residual)(Mat,Vec,Vec,Vec),Mat mat) ?
>
> I'm thinking to have this in the code:
>
> mglevels[l]->A = mat;
> mglevels[l]->residual = r
I'm not sure what to do with:
PetscErrorCode PCMGSetResidual(PC pc,PetscInt l,PetscErrorCode
(*residual)(Mat,Vec,Vec,Vec),Mat mat) ?
I'm thinking to have this in the code:
mglevels[l]->A = mat;
mglevels[l]->residual = residual;
and change the calls from using PCMGResidualDefault to using
On Thu, 12 Sep 2013, Jed Brown wrote:
> Satish Balay writes:
>
> > Jed,
> >
> > The sowing update is primarily required by
> > knepley/feature-plex-generic-distribute Hower I branched
> > 'balay/update-sowing' off master - and merged to next.
> >
> > Should I have directly commited to
> > kneple
Satish Balay writes:
> Jed,
>
> The sowing update is primarily required by
> knepley/feature-plex-generic-distribute Hower I branched
> 'balay/update-sowing' off master - and merged to next.
>
> Should I have directly commited to
> knepley/feature-plex-generic-distribute?
>
> Should I now merge b
Jed,
The sowing update is primarily required by
knepley/feature-plex-generic-distribute Hower I branched
'balay/update-sowing' off master - and merged to next.
Should I have directly commited to
knepley/feature-plex-generic-distribute?
Should I now merge balay/update-sowing into
knepley/feature-
Hi, now I'm trying to compile Petsc with mkl, not just for BLAS/LAPACK
functions, but for all functionalities of mkl. What I did until now is to add
the file mkl.py to config/PETSc/packages, with the following code:
import PETSc.package
class Configure(PETSc.package.NewPackage):
def __init__(
Here is the information in the file below. Simply put those libraries don't
resolve everything needed.
What you need to do is start by forgetting about PETSc. Just write a
program that calls the test function
int main() {
set_default_options()
;
return 0;
}
Now determine what Intel/
Satish Balay writes:
> There are a bunch of failures in the nightly builds. One of them is a
> failure with --download-triangle - triggered by the change with
> --download-make
>
> Should I commit the fix to balay/download-make or to jed/gmake?
I don't mind imprecise tracking within 'jed/gnumake'
On Thu, 12 Sep 2013, Jed Brown wrote:
> Satish Balay writes:
> > There are a bunch of failures in the nightly builds. One of them is a
> > failure with --download-triangle - triggered by the change with
> > --download-make
> >
> > Should I commit the fix to balay/download-make or to jed/gmake?
>
If A is B then ts->Arhs ends up not being ts->Brhs Thus when the RHSJacobian
function of the user is called it is called with two different matrices. If the
use does not fill up BOTH matrices then bad stuff happens. For example my
normal model is fill up to B and call MatAssemblyBegin/End()
On Wed, 11 Sep 2013, Satish Balay wrote:
> On Wed, 11 Sep 2013, Jed Brown wrote:
>
> > GNU Make is now the default in 'next'.
Jed,
There are a bunch of failures in the nightly builds. One of them is a
failure with --download-triangle - triggered by the change with
--download-make
Should I com
> >self.liblist = [['libmkl_intel_lp64.so', 'libmkl_intel_thread.so',
> > 'libmkl_core.so']]
Its probably wrong.
We have the following in BlasLapack.py
yield ('User specified MKL11/12 Linux64', None,
[os.path.join(dir,libdir,'libmkl_intel_lp64.a'),'mkl_sequential','mkl_core','pthread'
We absolutely need configure.log to debug this. All the information about
what variants were tried and why they failed are listed in configure.log
On Sep 12, 2013, at 10:41 AM, Jose David Bermeol wrote:
> Hi, now I'm trying to compile Petsc with mkl, not just for BLAS/LAPACK
> functions,
Jose,
I don't really understand why it is necessary to make an MKL package for PETSc.
I use MKL with
PETSc all the time. I configure PETSc to use MKL for blas/lapack with a
configure option like the
following:
configure \
--PETSC_DIR=$PETSC_DIR \
--PETSC_ARCH=$PETSC_ARCH \
21 matches
Mail list logo
