October 2018 - petsc-dev - mailman3.cels.anl.gov

why exist named global and local vectors
by Smith, Barry F. 05 Oct '18

05 Oct '18

Why have PETSC_EXTERN PetscErrorCode DMHasNamedGlobalVector(DM,const char*,PetscBool*); PETSC_EXTERN PetscErrorCode DMGetNamedGlobalVector(DM,const char*,Vec*); PETSC_EXTERN PetscErrorCode DMRestoreNamedGlobalVector(DM,const char*,Vec*); PETSC_EXTERN PetscErrorCode DMHasNamedLocalVector(DM,const char*,PetscBool*); PETSC_EXTERN PetscErrorCode DMGetNamedLocalVector(DM,const char*,Vec*); PETSC_EXTERN PetscErrorCode DMRestoreNamedLocalVector(DM,const char*,Vec*); when one can simply using the already existing PetscObjectCompose() and PetscObjectQuery() to attach named vectors to a given DM (or any other object in fact)? Barry

1 0

Re: [petsc-dev] Problems with VecScatterRemap() Fortran interface in PETSc 3.10
by Balay, Satish 05 Oct '18

05 Oct '18

There were 2 changes that appear to affect pflotran https://bitbucket.org/petsc/petsc/commits/3d1df95b16 Change Fortran null pointer to match C null pointer https://bitbucket.org/petsc/petsc/commits/487a658c8b Remove CHKFORTRANNULLOBJECTDEREFERENCE since it is no longer needed with Fortran null equal to C null The second one causes compile errors with pflotran. I have fixes in branch balay/revert_vecscatterremap_/maint However - the first one is causing regression failure in pflotran. I assumed pflotran requires fixes (patch attached) - but this is not working. >>>>> $ make check make[1]: Entering directory '/home/balay/git-repo/pflotran/src/pflotran' gmake[2]: Entering directory '/home/balay/git-repo/pflotran/regression_tests' /usr/bin/python regression_tests.py -e /home/balay/git-repo/pflotran/src/pflotran/pflotran --mpiexec mpiexec \ --suite standard standard_parallel \ --config-files ascem/1d/1d-calcite/1d-calcite.cfg Test log file : pflotran-tests-2018-10-05_16-56-18.testlog Running pflotran regression tests : FF ---------------------------------------------------------------------- Regression test summary: Total run time: 0.204805 [s] Total tests : 2 Tests run : 2 Failed : 2 gmake[2]: [Makefile:207: check] Error 2 (ignored) gmake[2]: Leaving directory '/home/balay/git-repo/pflotran/regression_tests' make[1]: Leaving directory '/home/balay/git-repo/pflotran/src/pflotran' <<<<< Richard, Would you be able to debug this? I noticed the current code has the following - so that overloading the new null def? $ git grep tVec$0$ src/pflotran/convergence.F90: residual_vec = tVec(0) src/pflotran/convergence.F90: solution_vec = tVec(0) src/pflotran/convergence.F90: update_vec = tVec(0) src/pflotran/pm_wipp_flow.F90: residual_vec = tVec(0) src/pflotran/timestepper_BE.F90: residual_vec = tVec(0) Satish ------------- On Fri, 5 Oct 2018, Mills, Richard Tran wrote: > Fellow PETSc developers (cc: PFLOTRAN developers), > > I am trying to get PFLOTRAN (which currently uses PETSc 3.9) working with the recent PETSc 3.10 release. One problem I am hitting is that VecScatterRemap() calls that were fine with PETSc 3.9 cause compile time errors due to mismatched ranks in some arguments. Digging around in the 3.10 source code, I see that in my auto-generated interfaces in $PETSC_DIR/src/vec/f90-mod/ftn-auto-interfaces/petscvec.h90 there is > > subroutine VecScatterRemap(a,b,c,z) > use petscvecdef > VecScatter a ! VecScatter > PetscInt b ! PetscInt > PetscInt c ! PetscInt > integer z > end subroutine > > but I think arguments b and c need to be defined something like > > PetscInt, dimension(:), pointer :: b > PetscInt, dimension(:), pointer :: c > > (Though my modern Fortran skills are rusty and I'm not sure if this is quite how these should be declared.) Note that this interface doesn't appear to be generated at all in PETSc 3.9. It's been a very long time since I've done any hacking on the Fortran interface stuff in PETSc. How do I go about fixing this? > > Related Fortran usage question: At one point in PFLOTRAN, there is the call > > call VecScatterRemap(ugdm%scatter_ltol,int_ptr,PETSC_NULL_INTEGER, & > ierr);CHKERRQ(ierr) > > If I manually change the Fortran interface code to be as above, then I get > > Error: Actual argument for 'c' must be a pointer at (1) > > If argument 'c' should indeed be defined as a pointer to a one-dimensional array, what variant of PETSC_NULL are we to pass? > > --Richard >

1 0

No LocalToGlobalMapping in DMPlex
by Tristan Konolige 05 Oct '18

05 Oct '18

Hello PETSc Developers, I’d like to get an ISLocalToGlobalMapping from a DMPlex. But, currently, DMGetLocalToGlobalMapping returns an empty ISLocalToGlobalMapping. I can see that ISLocalToGlobalMappings are created in DMPlexDistribute, but they are never assigned to the DM. Is DMGetLocalToGlobalMapping supported with DMPlex or is this a bug? I’ve included a simple example below. ``` #include <petsc.h> int main(int argc, char** argv) { PetscErrorCode ierr; PetscInt size; ISLocalToGlobalMapping l2g; DM dm, dm_dist; PetscInt num_points[2] = {2, 2}; PetscInt cone_size[4] = {1, 1, 0, 0}; PetscInt cones[2] = {2,3}; PetscInt orientations[2] = {0, 0}; PetscInt local_points[2] = {0, 1}; PetscInt global_points[2]; PetscInitialize(&argc, &argv, NULL, NULL); DMPlexCreate(PETSC_COMM_WORLD, &dm); DMPlexCreateFromDAG(dm, 1, num_points, cone_size, cones, orientations, NULL); DMPlexDistribute(dm, 0, NULL, &dm_dist); DMGetLocalToGlobalMapping(dm_dist, &l2g); ISLocalToGlobalMappingApply(l2g, 2, local_points, global_points); PetscFinalize(); } ``` Thank you, Tristan Konolige

1 0

Problems with VecScatterRemap() Fortran interface in PETSc 3.10
by Mills, Richard Tran 05 Oct '18

05 Oct '18

Fellow PETSc developers (cc: PFLOTRAN developers), I am trying to get PFLOTRAN (which currently uses PETSc 3.9) working with the recent PETSc 3.10 release. One problem I am hitting is that VecScatterRemap() calls that were fine with PETSc 3.9 cause compile time errors due to mismatched ranks in some arguments. Digging around in the 3.10 source code, I see that in my auto-generated interfaces in $PETSC_DIR/src/vec/f90-mod/ftn-auto-interfaces/petscvec.h90 there is subroutine VecScatterRemap(a,b,c,z) use petscvecdef VecScatter a ! VecScatter PetscInt b ! PetscInt PetscInt c ! PetscInt integer z end subroutine but I think arguments b and c need to be defined something like PetscInt, dimension(:), pointer :: b PetscInt, dimension(:), pointer :: c (Though my modern Fortran skills are rusty and I'm not sure if this is quite how these should be declared.) Note that this interface doesn't appear to be generated at all in PETSc 3.9. It's been a very long time since I've done any hacking on the Fortran interface stuff in PETSc. How do I go about fixing this? Related Fortran usage question: At one point in PFLOTRAN, there is the call call VecScatterRemap(ugdm%scatter_ltol,int_ptr,PETSC_NULL_INTEGER, & ierr);CHKERRQ(ierr) If I manually change the Fortran interface code to be as above, then I get Error: Actual argument for 'c' must be a pointer at (1) If argument 'c' should indeed be defined as a pointer to a one-dimensional array, what variant of PETSC_NULL are we to pass? --Richard

1 0

Re: [petsc-dev] PETSc tutorial
by Smith, Barry F. 04 Oct '18

04 Oct '18

Reminder to PETSc developers to update this page. https://www.mcs.anl.gov/petsc/documentation/tutorials/index.html Sajid, There are a variety of tutorials or slides on line at the above address. Barry > On Oct 4, 2018, at 4:11 PM, Sajid Ali <sajidsyed2021(a)u.northwestern.edu> wrote: > > Hi Barry, > > I was attending and ALCF workshop and when I asked about upcoming workshops for PETSc I was redirected to you. Could you let me know of any upcoming PETSc tutorials or workshops ? > > Thank You, > Sajid Ali > Applied Physics > Northwestern University

1 0

Re: [petsc-dev] Is mpich/master:a8a2b30fd21 tested with Petsc?
by Eric Chamberland 02 Oct '18

02 Oct '18

Hi, mainly for PETSc users: please do no waste your time using MPI released with Intel Parallel Studio 2019 since it is the buggy MPICH 3.3b2 for which this initial thread has been created... I just wrote a remind about this also on Intel forum: https://software.intel.com/en-us/forums/intel-clusters-and-hpc-technology/t… Eric On 19/04/18 09:01 AM, Eric Chamberland wrote: > Hi, > > this morning, mpich/master with PETSc is 100% working again for us. > > Thanks to both commits: > > https://github.com/pmodels/mpich/commit/c597c8d79deea220a42751fda0f01ce7076… > > > https://github.com/pmodels/mpich/commit/8edabc7373b82dd660019e53d2461317658… > > > and thanks to everybody who helped: > > Satish > Min > Wesley > Ken > Rob > Jed > > :) > > Eric > > On 17/04/18 04:58 PM, Min Si wrote: >> Hi all, >> >> Thanks for narrowing down the problem. I checked the MPICH code and >> believe this is a bug in MPICH. I just created a PR to fix it: >> https://github.com/pmodels/mpich/pull/3097 >> >> It should be merged into MPICH master branch soon. >> >> Thanks, >> Min >> >> On 2018/04/17 14:10, Eric Chamberland wrote: >>> Hi, >>> >>> are we talking about the "tag" passed to MPI_Isend for example? >>> >>> but does that mean there is something to change for any MPI call >>> which involves tags usage or is it only a PETSc "bad" tag usage? >>> >>> thanks Satish for your finding! >>> >>> Eric >>> >>> On 16/04/18 11:31 PM, Satish Balay wrote: >>>> On Tue, 13 Mar 2018, Eric Chamberland wrote: >>>> >>>>> Hi, >>>>> >>>>> each night we are testing mpich/master with our petsc-based code. >>>>> I don't >>>>> know if PETSc team is doing the same thing with mpich/master? >>>>> (Maybe it is a >>>>> good idea?) >>>>> >>>>> Everything was fine (except the issue >>>>> https://github.com/pmodels/mpich/issues/2892) up to commit >>>>> 7b8d64debd, but >>>>> since commit mpich:a8a2b30fd21), I have a segfault on a any >>>>> parallel nightly >>>>> test. >>>> >>>> I attempted a bisect of the above range of commits - and narrowed >>>> down to: >>>> >>>>>>>>>>> >>>> db11d4c4a70e39a28be88ed32f00542301699e08 is the first bad commit >>>> <<<<<<< >>>>>>>>>>>> >>>> balay@asterix /home/balay/soft/build/mpich ((db11d4c4a...)|BISECTING) >>>> $ git show db11d4c4a70e39a28be88ed32f00542301699e08 >>>> commit db11d4c4a70e39a28be88ed32f00542301699e08 (HEAD, refs/bisect/bad) >>>> Author: Ken Raffenetti <raffenet(a)mcs.anl.gov> >>>> Date: Thu Feb 15 11:37:59 2018 -0600 >>>> >>>> init: Fix tag upper limit initialization >>>> The starting point for this value is equivalent to the >>>> usable tag bits >>>> macro. This value should be set before device initialization, >>>> otherwise devices will assume they have more bits than are >>>> actually >>>> available. >>>> Signed-off-by: Wesley Bland <wesley.bland(a)intel.com> >>>> >>>> diff --git a/src/mpi/init/initthread.c b/src/mpi/init/initthread.c >>>> index cbc41f4d5..b31ae2f07 100644 >>>> --- a/src/mpi/init/initthread.c >>>> +++ b/src/mpi/init/initthread.c >>>> @@ -403,7 +403,7 @@ int MPIR_Init_thread(int *argc, char ***argv, >>>> int required, int *provided) >>>> MPIR_Process.attrs.host = MPI_PROC_NULL; >>>> MPIR_Process.attrs.io = MPI_PROC_NULL; >>>> MPIR_Process.attrs.lastusedcode = MPI_ERR_LASTCODE; >>>> - MPIR_Process.attrs.tag_ub = 0; >>>> + MPIR_Process.attrs.tag_ub = MPIR_TAG_USABLE_BITS; >>>> MPIR_Process.attrs.universe = MPIR_UNIVERSE_SIZE_NOT_SET; >>>> MPIR_Process.attrs.wtime_is_global = 0; >>>> @@ -531,13 +531,6 @@ int MPIR_Init_thread(int *argc, char ***argv, >>>> int required, int *provided) >>>> MPIR_Assert(((unsigned) MPIR_Process. >>>> attrs.tag_ub & ((unsigned) >>>> MPIR_Process.attrs.tag_ub + 1)) == 0); >>>> - /* Set aside tag space for tagged collectives and failure >>>> notification */ >>>> -#ifdef HAVE_TAG_ERROR_BITS >>>> - MPIR_Process.attrs.tag_ub >>= 3; >>>> -#else >>>> - MPIR_Process.attrs.tag_ub >>= 1; >>>> -#endif >>>> - >>>> /* Assert: tag_ub is at least the minimum asked for in the MPI >>>> spec */ >>>> MPIR_Assert(MPIR_Process.attrs.tag_ub >= 32767); >>>> <<<<<<<<<<<<<<<<< >>>> >>>> Reverthing this patch gets mpich-3.3b2 working with petsc >>>> >>>> Satish >>>>

1 0

Re: [petsc-dev] tiny issues in test harness
by Jakub Kruzik 01 Oct '18

01 Oct '18

This doesn't work for me on master or on ecc1beb596a8093f7509ca38016ed30c93784193 Jakub On 9/26/18 11:11 PM, Scott Kruger wrote: > > > I think this is fixed as well. Please let me know if it isn't. > > On 8/16/18 9:30 AM, Jakub Kruzik wrote: >> testset: >> nsize: 4 >> test: >> #suffix: 1 >

1 0

Re: [petsc-dev] tiny issues in test harness
by Jakub Kruzik 01 Oct '18

01 Oct '18

ecc1beb596a8093f7509ca38016ed30c93784193 works for me. Thanks! #2 Yes, using double quotes works, but it took me a while to figure out why the filter didn't work for me with single quotes. Might be worth mentioning that filters with single quotes might not work correctly in dev manual and/or putting guards into parsing/petsc_testrun. Jakub On 9/26/18 11:00 PM, Scott Kruger wrote: > > > Fix for #1 is merged into next. > > See ecc1beb596a8093f7509ca38016ed30c93784193 > > For #2, I think it'll work if you use double quotes and egrep. > If you do this: > cd $PETSC_DIR/src/sys/examples/test > grep filter *.c > > I think you'll see some examples of complicated filters that Barry got > working. > > Scott > > > On 8/14/18 4:05 AM, Jakub Kruzik wrote: >> Hi all, >> >> I started using test harness in PERMON and find out a couple of >> issues with it. >> >> 1) multiple "args:" keywords in "test:" in "testset:" are ignored >> except for the last "args:" keyword. See attached MWE and check it with >> >> python2 ${PETSC_DIR}/config/testparse.py -t ex1.c -v 3 >> >> 2) single quotes can't be used in "filter:" keyword. E.g. filter: >> grep 'r =' generates >> >> petsc_testrun ... 'grep 'r ='' >> >> resulting in filter being "grep r". Might be worth mentioning this in >> dev manual and/or putting guards into parsing/petsc_testrun. >> >> Best, >> >> Jakub >> >

1 0