Re: [petsc-users] Error configuring EXODUSII with cmake in petsc-3.13.2
From the configure.log: > -- Configuring incomplete, errors occurred!CMake Error at CMakeLists.txt:16 > (CMAKE_MINIMUM_REQUIRED): > CMake 3.10.0 or higher is required. You are running version 3.5.1 Best regards, Jacob Faibussowitsch (Jacob Fai - booss - oh - vitch) Cell: (312) 694-3391 > On Jun 3, 2020, at 4:04 PM, Danyang Su wrote: > > Hi All, > > I got following errors compiling PETSc-3.13.2 version. > === > > Trying to download git://https://github.com/gsjaardema/seacas.git for > EXODUSII > === > === > > Configuring EXODUSII with cmake, this may take several minutes > > === > > > *** > UNABLE to CONFIGURE with GIVEN OPTIONS(see configure.log for > details): > --- > Error configuring EXODUSII with cmake > *** > > Thanks, > > Danyang > > On 2020-06-02, 9:23 PM, "petsc-users on behalf of Satish Balay via > petsc-users" petsc-users@mcs.anl.gov> wrote: > >Dear PETSc users, > >The patch release petsc-3.13.2 is now available for download, >with change list at 'PETSc-3.13 Changelog' > >http://www.mcs.anl.gov/petsc/download/index.html > >Satish > > > >
Re: [petsc-users] TSAdjoint not working correctly when using TSThetaSetEndpoint(true)
Thanks! On Tue, Jun 2, 2020, 20:51 Zhang, Hong via petsc-users < petsc-users@mcs.anl.gov> wrote: > I checked the results again and can confirm that it is a bug on our side. > A merge request has been created to fix it: > https://gitlab.com/petsc/petsc/-/merge_requests/2830 > > Thanks, > Hong (Mr.) > > On Jun 2, 2020, at 6:26 PM, Salazar De Troya, Miguel < > salazardet...@llnl.gov> wrote: > > Hong, > > That is not the correct result, however, we can obtain the correct result > if we comment ts.setThetaEndpoint(True). Why is it so? > > Thanks > Miguel > > *From: *"Zhang, Hong" > *Date: *Tuesday, June 2, 2020 at 3:31 PM > *To: *"Salazar De Troya, Miguel" > *Cc: *"petsc-users@mcs.anl.gov" > *Subject: *Re: [petsc-users] TSAdjoint not working correctly when using > TSThetaSetEndpoint(true) > > Miguel, > > After I uncommented ts.setThetaEndpoint(True) and > removed ts.setProblemType(False.ProblemType.LINEAR) in your code, I got the > following result: > > hongzhang@Hongs-MacBook-Pro$ python3 petsc_question_2.py > Cost function > Vec Object: 1 MPI processes > type: seq > 127.781 > Exact value: 127.78112 > > Numerical sensitivity w.r.t. a > 12.778122049945212 > Real sensitivity w.r.t a > 12.7781121978613 > > Numerical sensitivity w.r.t. b > 83.8907580310942 > Real sensitivity w.r.t b > 211.67168296791954 > > -ts_type cn gives the same result. What was the problem you encountered? > > Thanks, > Hong (Mr.) > > > On Jun 2, 2020, at 2:36 PM, Salazar De Troya, Miguel via petsc-users < > petsc-users@mcs.anl.gov> wrote: > > Hello, > > I am attaching a simple example that uses TSAdjoint to calculate the > sensitivity of a 1 degree of freedom ODE. When using theta methods, it > returns the right sensitivity as given by the analytical solution. When I > set `ts.setThetaEndpoint(True)`, it does not work. Is there a theoretical > reason why? I was using this option because using the options > > ts.setType(ts.Type.THETA) > ts.setTheta(0.5) > ts.setThetaEndpoint(True) > > is equivalent to using ts.Type.CN > > Thanks > Miguel > > Miguel A. Salazar de Troya > Postdoctoral Researcher, Lawrence Livermore National Laboratory > B141 > Rm: 1085-5 > Ph: 1(925) 422-6411 > > > >
Re: [petsc-users] Using "long int" variable in MatSetValues
Its best to use PetscInt here.
Satish
On Tue, 2 Jun 2020, Evan Um wrote:
> Hi Satish,
>
> Thanks for your reply.
> When the code is compiled using the petsc library built with the option, an
> error message suggests that I need to use 'long long' rather than 'int'. I
> can replace variable types with long long in my codes, but I am wondering
> if there is any better way. If I replace 'int' with 'long long', it means
> that I have to maintain two versions of PETSC application codes for small
> and big problems.
>
> Best,
> Evan
>
> On Tue, Jun 2, 2020 at 1:47 PM Satish Balay wrote:
>
> > You need PetscInt to be 64-bit-integer - so rebuild PETSc with the option:
> > --with-64-bit-indices=1
> >
> > Satish
> >
> > On Tue, 2 Jun 2020, Evan Um wrote:
> >
> > > Dear PETSC users,
> > >
> > > Using C++, I tried to build a very large sparse matrix and had a problem
> > > shown below. Indices of the matrix should be "long int" rather than "int"
> > > but PETSC does not allow this. How could I dodge this problem? Thanks for
> > > your comments.
> > >
> > > Regards,
> > > Evan
> > >
> > > fe.cpp(2009): error: argument of type "long *" is incompatible with
> > > parameter of type "const PetscInt={int} *"
> > > ierr=MatSetValues(Bseq, 1, _b_i_partitioned[i], 1,
> > > _b_j_partitioned[i], _b_val_partitioned[i], ADD_VALUES);
> > >
> >
> >
>
Re: [petsc-users] Using "long int" variable in MatSetValues
Hi Satish,
Thanks for your reply.
When the code is compiled using the petsc library built with the option, an
error message suggests that I need to use 'long long' rather than 'int'. I
can replace variable types with long long in my codes, but I am wondering
if there is any better way. If I replace 'int' with 'long long', it means
that I have to maintain two versions of PETSC application codes for small
and big problems.
Best,
Evan
On Tue, Jun 2, 2020 at 1:47 PM Satish Balay wrote:
> You need PetscInt to be 64-bit-integer - so rebuild PETSc with the option:
> --with-64-bit-indices=1
>
> Satish
>
> On Tue, 2 Jun 2020, Evan Um wrote:
>
> > Dear PETSC users,
> >
> > Using C++, I tried to build a very large sparse matrix and had a problem
> > shown below. Indices of the matrix should be "long int" rather than "int"
> > but PETSC does not allow this. How could I dodge this problem? Thanks for
> > your comments.
> >
> > Regards,
> > Evan
> >
> > fe.cpp(2009): error: argument of type "long *" is incompatible with
> > parameter of type "const PetscInt={int} *"
> > ierr=MatSetValues(Bseq, 1, _b_i_partitioned[i], 1,
> > _b_j_partitioned[i], _b_val_partitioned[i], ADD_VALUES);
> >
>
>
