Re: [petsc-dev] User(s) manual sections field in manual pages?

Lawrence Mitchell writes: >> On 17 Jun 2019, at 19:50, Jed Brown via petsc-dev >> wrote: > > [...] >> >> As for strategy, we have these primary forms of documentation: >> >> * Users Manual >> >> A lot of value here is in cross-refer

Re: [petsc-dev] User(s) manual sections field in manual pages?

Patrick Sanan writes: > What are the options for incrementalism with this general approach? Does it > make much sense to say "let's make sure the manual is online first, and > then later we can update the man pages and tutorials?". Note: The above "incrementalism" is different from my previous

Re: [petsc-dev] User(s) manual sections field in manual pages?

Jed Brown via petsc-dev writes: > Scott Kruger writes: > >>>> So many projects use it (including the linux kernel, moving away from >>>> bookdown, says wikipedia) >>> >>> They switched from Docbook to rst. >>> >>>https://w

Re: [petsc-dev] moving from BitBucket to GitLab

"Zhang, Hong via petsc-dev" writes: > If it is mainly because of CI, why don't we host petsc on GitHub and use the > GitLab CI? > https://about.gitlab.com/solutions/github/ There are significant missing features for that mode of operation. https://gitlab.com/gitlab-org/gitlab-ce/issues/60158

Re: [petsc-dev] User(s) manual sections field in manual pages?

Scott Kruger writes: >>> So many projects use it (including the linux kernel, moving away from >>> bookdown, says wikipedia) >> >> They switched from Docbook to rst. >> >>https://www.kernel.org/doc/html/latest/ > > Is that the default C autodoc extension, or hawkmoth? > >

Re: [petsc-dev] User(s) manual sections field in manual pages?

I also use singleindex. Sphinx can do substring matching and wildcards, but I don't think autocomplete support exists (which is surprising given that there's an obvious need and the developers must know how to implement it). Patrick Sanan writes: > I've just learned to use google or, when

Re: [petsc-dev] User(s) manual sections field in manual pages?

Patrick Sanan writes: > It'd be huge if pandoc can do the heavy lifting of converting the manual to > a human-readable-yet-html-renderable format. As a stopgap, particularly > ornery sections of latex could perhaps be compiled as standalone pdfs and > included. > > .rst seems like a reasonably

Re: [petsc-dev] better regular testing on accelerators

Would it be sufficient to add the CUDA arguments to PETSC_OPTIONS when running the test suite on those machines? "Smith, Barry F. via petsc-dev" writes: >In order to get better testing on the accelerators I think we need to > abandon the -vec_type cuda approach scattered through a handful

Re: [petsc-dev] User(s) manual sections field in manual pages?

Thanks for starting this thread, Patrick. For the users manual, my plan is to do some mild cleanup so that pandoc can convert it to Markdown or rST. From there, the two systems I'm familiar with are Sphinx and Bookdown. Everyone has seen Sphinx output on readthedocs sites. Bookdown is fast and

Re: [petsc-dev] error in Jenkins but not nightly

"Smith, Barry F." writes: > That seems ok. We could also overload --download-mpich=spack for anal > people like me :-) > > Somehow we also need to let configure know where the spack configuration > is. Right, --with-spack=/path/to/spack/bin/spack or use spack from PATH if it's there.

Re: [petsc-dev] error in Jenkins but not nightly

"Smith, Barry F." writes: > Yes, spack could be used to do this. I guess essentially Buildsystem would > issues commands to spack on each "prebuilt" package each time it runs in test > mode (using the URL in the package file?) and after the first time spack > would ignore the commands since

Re: [petsc-dev] error in Jenkins but not nightly

"Smith, Barry F. via petsc-dev" writes: > Yes. If the testing system were smart enough we could have the tests > actually update the "prebuilt" automatically when things change. This would > be more scalable in human efficiency. In addition when setting up a new test > machine no need to

Re: [petsc-dev] Bad use of defined(MPI_XXX)

Lisandro Dalcin via petsc-dev writes: > On Sat, 25 May 2019 at 06:20, Smith, Barry F. via petsc-dev < > petsc-dev@mcs.anl.gov> wrote: > >> >> MS-MPI has in their include file >> >> #define MPI_VERSION 2 >> #define MPI_SUBVERSION 0 >> >> Their last release was Oct 2018 >>

Re: [petsc-dev] Bad use of defined(MPI_XXX)

Lisandro Dalcin writes: > On Sat, 25 May 2019 at 07:08, Jed Brown via petsc-dev > wrote: > >> To be fair, Microsoft just doesn't have resources left over for MPI >> after all they've been putting into making sure nobody in China learns >> about Tiananmen Square. &

Re: [petsc-dev] Bad use of defined(MPI_XXX)

gt;> > How about stuff in MPI-2.2 (approved in 2009), the last of MPI-2.x, e.g., >> > PETSC_HAVE_MPI_REDUCE_LOCAL? >> >> Currently we only require MPI-2.0, but I would not object to increasing >> to MPI-2.1 or 2.2 if such systems are sufficiently rare (alm

Re: [petsc-dev] Bad use of defined(MPI_XXX)

ent) in the wild. I'm not sure how great the benefits are. > On Fri, May 24, 2019 at 2:51 PM Jed Brown via petsc-dev > mailto:petsc-dev@mcs.anl.gov>> wrote: > Lisandro Dalcin via petsc-dev > mailto:petsc-dev@mcs.anl.gov>> writes: > >> These two are definitely wron

Re: [petsc-dev] Bad use of defined(MPI_XXX)

Lisandro Dalcin via petsc-dev writes: > These two are definitely wrong, we need PETSC_HAVE_MPI_XXX instead. Thanks, we can delete both of these cpp guards. > include/petscsf.h:#if defined(MPI_REPLACE) MPI-2.0 > src/sys/objects/init.c:#if defined(PETSC_USE_64BIT_INDICES) || >

Re: [petsc-dev] Cross-compiling/batch systems and getting rid of --know-sizeof- (or at least making it not required at all)

test with MS compiler (cl), sun/solaris (cc) - it worked with > both. > > Also worked with 'gcc -std=c89' > > Satish > > On Wed, 22 May 2019, Jed Brown via petsc-dev wrote: > >> Agreed, though need to test that all relevant compilers error >> appropriately (and th

Re: [petsc-dev] Cross-compiling/batch systems and getting rid of --know-sizeof- (or at least making it not required at all)

Agreed, though need to test that all relevant compilers error appropriately (and that we accurately detect such errors). Satish may remember which are most problematic. There are a few other --known arguments that we may need to think about. I think these are tough:

Re: [petsc-dev] (no subject)

VS Code is MIT licensed and works on Linux too. It's an electron app front-end like Atom (which I know Matt has some fondness for), though used less resources when I tried opening a few hundred source files. o_O "Smith, Barry F. via petsc-dev" writes: > Actually Visual Studio works in Mac

Re: [petsc-dev] https://www.dursi.ca/post/hpc-is-dying-and-mpi-is-killing-it.html

"Smith, Barry F. via petsc-dev" writes: >> On May 16, 2019, at 6:16 PM, Mills, Richard Tran wrote: >> >> OK, so this thread is two months old but I saw some things recently that >> reminded me of it. >> >> To answer Barry's first question: I think that "AI" was used more than "HPC" >>

Re: [petsc-dev] Is bitbucket less responsive than it use to be?

FWIW, mention of GitLab focuses on network effects, not the technical merits. Network effects are real, though I think a monoculture is hazardous in the long term.I don't know how to valuate the difference in network effect for GitLab vs GitHub. I really like the CI integration in GitLab, but

Re: [petsc-dev] [petsc-maint] circular dependency [nightlybuilds did not catch]

"Smith, Barry F. via petsc-maint" writes: > Yes you have the history exactly right, but keeping them as independent > beasts seemed/seems impossible; except by doing something very cumbersome > (like shoving all the PCXXX_YYY that depended on KSP into the KSP src > directory). So the

Re: [petsc-dev] [petsc-maint] circular dependency [nightlybuilds did not catch]

Václav Hapla writes: > 4. května 2019 14:21:31 GMT+03:00, Jed Brown napsal: >>Noting this historic event of Barry endorsing the addition of a new >>acronym with no specific demonstrated need. >> >>Note that most/all packages contain objects other that that which they >>are named after.

Re: [petsc-dev] [petsc-maint] circular dependency [nightlybuilds did not catch]

Noting this historic event of Barry endorsing the addition of a new acronym with no specific demonstrated need. Note that most/all packages contain objects other that that which they are named after. ksp/pc/, dm/label/, mat/partition/, snes/linesearch, etc. "Smith, Barry F." writes: > Ok >

Re: [petsc-dev] [petsc-maint] circular dependency [nightlybuilds did not catch]

"Smith, Barry F." writes: >> When we are at it, why we sometimes have types.h and sometimes not? > > We add these "as needed"; Jed can explain better exactly when they are > needed. We did some of them to limit header dependencies. For example:

Re: [petsc-dev] Bogus tag

h this] > > Satish > > On Fri, 3 May 2019, Jed Brown via petsc-dev wrote: > >> Gross. I deleted it. >> >> That was created when I was trying to label a PR in the web interface. >> It didn't work as intended, but I didn't realize it had left behind a >&

Re: [petsc-dev] alternatives to alt files

Hapla Vaclav via petsc-dev writes: > I'm not sure you about this nomenclature. Let me take DMPlexInterpolate as an > example: > So (1) comparing the actual view of the interpolated mesh to the snapshot > stored in the output file would be an integration test, whereas (2) calling a > set of

Re: [petsc-dev] Bogus tag

Gross. I deleted it. That was created when I was trying to label a PR in the web interface. It didn't work as intended, but I didn't realize it had left behind a Git tag in the repository. Lisandro Dalcin via petsc-dev writes: > $ git branch > * master > > $ git describe > WIP-112-g872c329e82

Re: [petsc-dev] alternatives to alt files

A recent post comparing performance of some of those unit testing frameworks. http://www.duskborn.com/posts/utest-h-performance/ My point about integration tests is that if we had more unit tests, the integration tests could have less reliance on long-form convergence logs, thus reducing the

Re: [petsc-dev] PetscViewerASCIIPushSynchronized

"Smith, Barry F." writes: >> On May 2, 2019, at 6:15 PM, Jed Brown wrote: >> >> I think this is a consequence of PetscViewerFlush_ASCII flushing any >> synchronized messages (code is basically copied from >> PetscSynchronizedFlush). >> >> if (vascii->allowsynchronized) { >>PetscMPIInt

Re: [petsc-dev] alternatives to alt files

Karl Rupp via petsc-dev writes: > Hi, > >> Scott and PETSc folks, >> >> Using alt files for testing is painful. Whenever you add, for example, >> a new variable to be output in a viewer it changes the output files and you >> need to regenerate the alt files for all the test

Re: [petsc-dev] PetscViewerASCIIPushSynchronized

I think this is a consequence of PetscViewerFlush_ASCII flushing any synchronized messages (code is basically copied from PetscSynchronizedFlush). if (vascii->allowsynchronized) { PetscMPIInt tag,i,j,n = 0,dummy = 0; char *message; MPI_Statusstatus; ierr =

Re: [petsc-dev] DMDA VTK viewer regression: field names missing

Patrick Sanan writes: > Am Mi., 3. Apr. 2019 um 21:26 Uhr schrieb Jed Brown : > >> Patrick Sanan via petsc-dev writes: >> >> > I was going to say something similar to Matt; to me it is worth the 1.5x >> > redundancy in the data if I can just view the output file with "doing >> > anything

Re: [petsc-dev] Thoughts on pushing current CI infrastructure to the next level

Karl Rupp writes: > On 4/25/19 6:53 PM, Jed Brown wrote: >> Karl Rupp via petsc-dev writes: >> >>> With some effort we can certainly address 1.) and to some extent 3.), >>> probably 4.) as well, but I don't know how to solve 2.) and 5.) with >>> Jenkins. Given that a significant effort is

Re: [petsc-dev] Thoughts on pushing current CI infrastructure to the next level

Karl Rupp via petsc-dev writes: > With some effort we can certainly address 1.) and to some extent 3.), > probably 4.) as well, but I don't know how to solve 2.) and 5.) with > Jenkins. Given that a significant effort is required for 1.), 3.) and > 4.) anyway, I'm starting to get more and

Re: [petsc-dev] TS RHS Jacobian caching (shift/scaling) in PETSc

Can you make a PR with a test to cover this feature? We desperately need coverage as a CI integration. Stefano Zampini writes: > Jed, > > It appears that the testsuite does not currently cover a nasty code we have > to cache RHS Jacobian computation when using the implicit interface. If I >

Re: [petsc-dev] testing in parallel

I don't know how this would happen and haven't noticed it myself. Perhaps Scott can help investigate. It would help to know which tests run in each case. To debug, I would make a dry-run or skip-all mode that skips actually running the tests and just reports success (or skip). Stefano Zampini

Re: [petsc-dev] testing in parallel

Stefano Zampini via petsc-dev writes: > Scott, > > I have noticed that make -j20 -f gmakefile.test test globsearch="mat*" does > not always run the same number of tests. How hard is to fix this race > condition in the generation of the rules? Can you reproduce with the print-test target? These

Re: [petsc-dev] Fwd: [firedrake] Dockerised build tests.

Lawrence Mitchell via petsc-dev writes: >> On 11 Apr 2019, at 21:02, Matthew Knepley via petsc-dev >> wrote: >> >> Jed, should we be doing this? My first impression is that our builds catch a >> lot of configure errors so we do not want it. > > We still configure and build firedrake in the

Re: [petsc-dev] Fwd: [firedrake] Dockerised build tests.

You mean using it for all the dependencies? Most commits don't change anything in the config/ tree, so we don't need to re-run configure. But they do generally change the source so we'd still need to build PETSc. We could set up caching to only rebuild what is needed, but the details of the

Re: [petsc-dev] Deprecation strategy for Enums

"Zhang, Junchao via petsc-dev" writes: > We should have a mechanism to auto-detect API-breaking commits and then we > can fix them before release. We should have our CI system flag PRs that fail this checker to confirm that it's documented in changes/dev.html and that the change is really

Re: [petsc-dev] Deprecation strategy for Enums

I think this would have the desired effect. diff --git i/include/petscksp.h w/include/petscksp.h index 7b1e877e29..b0fddedfcd 100644 --- i/include/petscksp.h +++ w/include/petscksp.h @@ -448,6 +448,7 @@ typedef enum {/* converged */ KSP_DIVERGED_NANORINF= -9,

Re: [petsc-dev] NVIDIA cuTENSOR library for accelerating tensor operations

There is already a library called cuTensor, but it is not this "pre-release", which I can't find on the internet. http://www.tensorlet.com/cutensor/ It might be useful for high order elements if they can support fusing enough kernels, but is probably of limited utility if each contraction

Re: [petsc-dev] DMDA VTK viewer regression: field names missing

Matthew Knepley writes: > On Thu, Apr 4, 2019 at 11:52 AM Jed Brown wrote: > >> Matthew Knepley writes: >> >> > On Thu, Apr 4, 2019 at 12:26 AM Jed Brown via petsc-dev < >> > petsc-dev@mcs.anl.gov> wrote: >> > >> >> Patric

Re: [petsc-dev] DMDA VTK viewer regression: field names missing

Matthew Knepley writes: > On Thu, Apr 4, 2019 at 12:26 AM Jed Brown via petsc-dev < > petsc-dev@mcs.anl.gov> wrote: > >> Patrick Sanan via petsc-dev writes: >> >> > I was going to say something similar to Matt; to me it is worth the 1.5x >> > redunda

Re: [petsc-dev] DMDA VTK viewer regression: field names missing

Patrick Sanan via petsc-dev writes: > I was going to say something similar to Matt; to me it is worth the 1.5x > redundancy in the data if I can just view the output file with "doing > anything special". I have also done something similar to what you're > describing with save states, and it

Re: [petsc-dev] SNESSolve and changing dimensions

Pierre Jolivet via petsc-dev writes: > I am just adapting the mesh depending on the solution from the previous > SNESSolve. > At first, I wanted to avoid writing an outer loop around the SNESSolve, so I > thought, let’s put the adaptation in the SNESSetJacobian. > It would have been preferable

Re: [petsc-dev] git repo branches housekeeping

"Balay, Satish" writes: > On Mon, 1 Apr 2019, Jed Brown via petsc-dev wrote: > >> "Smith, Barry F. via petsc-dev" writes: >> >> >This is, IMHO, a weakness of git. It is crazy to impose this type of >> > housekeeping directly on all

Re: [petsc-dev] Would this make sense?

Matthew Knepley via petsc-dev writes: > https://ford-foundation-6.forms.fm/digital-infrastructure-research-rfp/forms/4770 "Submissions were due on Jun 13, 2018 at 9:59pm." > Perhaps we would get funds to > > 1) Cloudize our usage, along the lines Jed has been going > > 2) Harden the

Re: [petsc-dev] git repo branches housekeeping

"Smith, Barry F. via petsc-dev" writes: >This is, IMHO, a weakness of git. It is crazy to impose this type of > housekeeping directly on all 1000 users of a repository. Perhaps this should be the default: git config --global fetch.prune true But, it would make it harder to recover if

Re: [petsc-dev] git repo branches housekeeping

"Balay, Satish via petsc-dev" writes: >> Would it make sense to make this cleanup in a regular basis? Once a PR is >> merged into master, what's the point of keeping the branch around until >> next release? It makes it heavier to search for a branch in Bitbucket, "git >> remote show origin"

Re: [petsc-dev] DMDA VTK viewer regression: field names missing

Matthew Knepley writes: > On Wed, Mar 27, 2019 at 10:56 PM Jed Brown via petsc-dev < > petsc-dev@mcs.anl.gov> wrote: > >> Prior to this PR, which was merged for 3.10 >> >> >> https://bitbucket.org/petsc/petsc/pull-requests/1029/dmda-vtk-viewing-output-multi

Re: [petsc-dev] Is there a good reason that BuildSystem's cuda.py requires GNU compilers?

"Balay, Satish via petsc-dev" writes: > Hm for CXXFLAGS - I think you have to do: > > self.pushLanguage('Cxx') > CXXFLAGS = self.getCompilerFlags() > self.popLanguage() These days, it's better to write this using the context manager: with self.Language('Cxx'): CXXFLAGS =

[petsc-dev] DMDA VTK viewer regression: field names missing

Prior to this PR, which was merged for 3.10 https://bitbucket.org/petsc/petsc/pull-requests/1029/dmda-vtk-viewing-output-multiple-dof/diff https://bitbucket.org/petsc/petsc/commits/ea2d7708fa6 we could have files that look like the following, and thus were easy to navigate in Paraview and

Re: [petsc-dev] OpenMP for GPU course

"Smith, Barry F." writes: >> On Mar 19, 2019, at 12:17 PM, Jed Brown wrote: >> >> Matthew Knepley writes: >> >>> Are you saying that using OpenMP 4.5 "offload" is something you would do? >> >> For applications that make sense for GPUs, yes. > > Oh, so you mean for AI ;) We really missed

Re: [petsc-dev] OpenMP for GPU course

Matthew Knepley writes: > Are you saying that using OpenMP 4.5 "offload" is something you would do? For applications that make sense for GPUs, yes.

Re: [petsc-dev] OpenMP for GPU course

These are well-organized events that puts application teams together with compiler developers and the like. I served as a mentor for the Boulder hackathon last year (joining a NASA team that included PETSc user Gaetan Kenway) and learned a lot. It's highly recommended to prepare for the event by

Re: [petsc-dev] https://www.dursi.ca/post/hpc-is-dying-and-mpi-is-killing-it.html

Jeff Hammond writes: > When this was written, I was convinced that Dursi was wrong about > everything because one of the key arguments against MPI was > fault-intolerance, which I was sure was going to be solved soon. However, > LLNL has done everything in their power to torpedo MPI

Re: [petsc-dev] https://www.dursi.ca/post/hpc-is-dying-and-mpi-is-killing-it.html

"Smith, Barry F. via petsc-dev" writes: > I stubbled on this today; I should have seen it years ago. https://lists.mpich.org/pipermail/devel/2015-April/000536.html https://twitter.com/KpDooty/status/585763759777574912 Proposing, as replacements for MPI, systems with no successful libraries

Re: [petsc-dev] Size of " PetscInt *garray" in Mat_MPIAIJ

Fande Kong writes: > Does mat->cmap->N= mat->A->cmap->N + mat->B->cmap->N?? No. garray translates from the column space for the Seq matrix B to the full matrix.

Re: [petsc-dev] Size of " PetscInt *garray" in Mat_MPIAIJ

Fande Kong via petsc-dev writes: > Hi Developers, > > What is the size of " PetscInt *garray" in Mat_MPIAIJ? Will it be > mat->B->cmap->N? Yes. > If so, it is not scalable in terms of the problem size, right? I am > missing something here. No, B only has columns for off-process entries

Re: [petsc-dev] errors with cuda + mumps

"Balay, Satish via petsc-dev" writes: > mailers that only format html and not the text form are annoying :( Amen.

Re: [petsc-dev] MPI_UB is deprecated in MPI-2.0

"petsc-dev on behalf of Jed Brown via petsc-dev" > wrote: > > I don't understand what you mean that it's "still there in the library". > > This goes along with other MPI-3.0 removals actually taking place in > this implementation. > &g

Re: [petsc-dev] MPI_UB is deprecated in MPI-2.0

I don't understand what you mean that it's "still there in the library". This goes along with other MPI-3.0 removals actually taking place in this implementation. Lisandro Dalcin via petsc-dev writes: > Please note that OpenMPI 4.0.0 actually removed MPI_UB from mpi.h; the > symbol is still

Re: [petsc-dev] MPI_UB is deprecated in MPI-2.0

MPI_Type_create_resized (if needed). "Balay, Satish via petsc-dev" writes: > http://ftp.mcs.anl.gov/pub/petsc/nightlylogs/archive/2019/03/01/make_master_arch-linux-pkgs-64idx_thrash.log > has the following [but for some reason - its filtered out from the warning > count] > > In file

Re: [petsc-dev] Is there a good reason that BuildSystem's cuda.py requires GNU compilers?

Richard, are you not on petsc-maint? There was a thread about this today. PGI "community edition" is free now. We could add it to our test suite. https://www.pgroup.com/products/community.htm "Smith, Barry F. via petsc-dev" writes: > Richard, > > You need to remove the isGNU() test

Re: [petsc-dev] PETSc-3.10.4 with Python3

No, Python-3 support is in 'master'. Antonio Trande via petsc-dev writes: > Hi all. > > Does exist a patch for compiling PETSc-3.10.4 with Python3? > > -- > --- > Antonio Trande > Fedora Project > mailto 'sagitter at fedoraproject dot org' > GPG key: 0x6e0331dd1699e4d7 > GPG key server:

Re: [petsc-dev] How long?

Rewrites are super risky and the subject of classic articles. https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ (NB: Firefox might not exist today if not for that rewrite. But they probably would have done better at retaining market share and thus had more money for

Re: [petsc-dev] MATCOMPOSITE as fallback for matrix-matrix multiplication

Matthew Knepley writes: > On Mon, Mar 11, 2019 at 6:59 PM Jed Brown via petsc-dev < > petsc-dev@mcs.anl.gov> wrote: > >> One could imagine PETSc written so that all Mat operations like >> transpose and products return lazy representations, with a method that &

Re: [petsc-dev] How long?

It's a solvable problem so long as compute nodes can execute preferred compilers (which for Julia, means LLVM). Current precompilation support can get you much of the way. Julia has run at large scale. It required some customization, but most of that work generalizes.

Re: [petsc-dev] MATCOMPOSITE as fallback for matrix-matrix multiplication

One could imagine PETSc written so that all Mat operations like transpose and products return lazy representations, with a method that makes it explicit. Would eliminate all the Transpose variants in the matrix products, for example, and enable an implementation to choose order of operations for

Re: [petsc-dev] [EXTERNAL] Re: external preconditioner availablilty for PETSc

Yeah, I wouldn't get bogged down in that. I would work on the good methods and then use as a reference those components without the composition. For example, you might use Hypre's BoomerAMG inside a composed preconditioner. You could run it on its own to show that the chosen structure was

Re: [petsc-dev] external preconditioner availablilty for PETSc

>From a research perspective, it doesn't make sense to view these preconditioners as black boxes. Your problem will likely have an elliptic component (which you might approach using a multilevel method such as PCGAMG, PCML, PCHYPRE, or PCBDDC, all of which can accept some problem-specific input

Re: [petsc-dev] Why do we use void* instead of PetscObject in PETSc?

Dave May writes: > On Mon, 4 Mar 2019 at 21:30, Jed Brown wrote: > >> If reusing, would the interface require >> casting the function pointers to void(*)(void) instead of what is >> currently type-safe for most function pointers? > > > No. I don't see that casting a function pointer would be

Re: [petsc-dev] Why do we use void* instead of PetscObject in PETSc?

Dave May via petsc-dev writes: > I think there would be a lot of merit (in the long run) if user contexts, > such as given to KSPSetComputeOperators(), SNESSetJacobian() etc were > changed to be of type PetscObject rather than void*. > > Some obvious benefits would be: > [1] Type checking! How

Re: [petsc-dev] KSPMonitor and petsc4py

I think Lisandro's point is that KSPSolve does not set ksp->its = 0. That happens in each KSPSolve_XXX. The Python implementation of a KSP forgot to do that, but perhaps it should happen in KSPSolve. "Smith, Barry F. via petsc-dev" writes: > I'm a bit confused. Since the C KSPSolve() always

Re: [petsc-dev] Note about CPR preconditioner in PCFIELDSPLIT man page?

..@gmail.com> writes: > > > > On Sun, Mar 3, 2019 at 12:58 AM Jed Brown via petsc-dev < > petsc-dev@mcs.anl.gov<mailto:petsc-dev@mcs.anl.gov>> wrote: > > > > My take is that someone looking for CPR is more likely to end up on the > PCFIELDSPLIT manual p

Re: [petsc-dev] Note about CPR preconditioner in PCFIELDSPLIT man page?

Matthew Knepley writes: > On Sun, Mar 3, 2019 at 12:58 AM Jed Brown via petsc-dev < > petsc-dev@mcs.anl.gov> wrote: > >> My take is that someone looking for CPR is more likely to end up on the >> PCFIELDSPLIT manual page than the PCGALERKIN page. The solver you have

Re: [petsc-dev] Note about CPR preconditioner in PCFIELDSPLIT man page?

My take is that someone looking for CPR is more likely to end up on the PCFIELDSPLIT manual page than the PCGALERKIN page. The solver you have configured in your mail is not the CPR we have been asked about here. See Barry's message and example code below. --- Begin Message --- Ok, I have

Re: [petsc-dev] Errors in MatSetValuesBlockedLocal() when using AIJ, but not BAIJ!

What's your minimal reproducer? "Mills, Richard Tran via petsc-dev" writes: > On 2/21/19 1:48 PM, Smith, Barry F. wrote: > > > > > > On Feb 20, 2019, at 12:50 PM, Mills, Richard Tran via petsc-dev > wrote: > > Folks, > > I'm working with some PFLOTRAN examples,

Re: [petsc-dev] Regression in Vec assembly

https://bitbucket.org/petsc/petsc/pull-requests/1389/vecstashsortcompress_private-fix/diff Stefano Zampini writes: > Jed, > > thanks. It fixed my issue too. > > > Il giorno mer 20 feb 2019 alle ore 09:33 Lisandro Dalcin > ha scritto: > >> I tested your fix (on top of master) with my original

Re: [petsc-dev] Regression in Vec assembly

Yuck, bad bug. I pushed a one-line fix to your branch. Can you let me know if there are any outstanding issues? If it solves the problem for you, I'll cherry-pick it to 'maint'. Thanks. Stefano Zampini writes: > In the link I have sent you, ex29 was modified to invert the order of values >

Re: [petsc-dev] Regression in Vec assembly

Is this what I'm supposed to see? What should I be looking at? $ mpiexec.hydra -n 3 mpich-clang/tests/vec/vec/examples/tests/ex29 -n 126 -info | grep malloc [0] VecAssemblyBegin_MPI_BTS(): Stash has 252 entries, uses 2 mallocs. [0] VecAssemblyBegin_MPI_BTS(): Block-Stash has 0 entries, uses 0

Re: [petsc-dev] How to add root values to leaves in PetscSF?

"Zhang, Junchao" writes: > On Tue, Jan 22, 2019 at 4:08 PM Jed Brown > mailto:j...@jedbrown.org>> wrote: >> It is not supported at this time. What does your use case look like? >> Do roots have degree greater than 1? > > Yes. Imagine a vecscatter x[0]->y[0], x[1]->y[0], x[1]->y[1],x[2]->y[1].

Re: [petsc-dev] How to add root values to leaves in PetscSF?

It is not supported at this time. What does your use case look like? Do roots have degree greater than 1? "Zhang, Junchao via petsc-dev" writes: > On Tue, Jan 22, 2019 at 1:35 PM Matthew Knepley > mailto:knep...@gmail.com>> wrote: > On Tue, Jan 22, 2019 at 2:23 PM Zhang, Junchao via petsc-dev

Re: [petsc-dev] setting viewer format from options

"Smith, Barry F. via petsc-dev" writes: >I'm very hesitant to have the -viewer_format supported by PETSc >because it reintroduces the concept of "setting" the viewer format, >as opposed to pushing and popping formats. I think it is a mistake >to have both the ability to set the

Re: [petsc-dev] setting viewer format from options

Hapla Vaclav via petsc-dev writes: > So is it wise to do that as Matt wrote? It would basically make > PetscViewerSetFromOptions() non-reentrant. I think non-idempotent is the word you're looking for here. Reentrancy refers to being able to call the function from an interrupt handler and

Re: [petsc-dev] Segmentation faults in MatMatMult & MatTransposeMatMult

Matthew Knepley writes: > On Wed, Jan 16, 2019 at 9:01 AM Jed Brown via petsc-dev < > petsc-dev@mcs.anl.gov> wrote: > >> Pierre Jolivet via petsc-dev writes: >> >> > OK, I was wrong about MATAIJ, as Jed already pointed out. >> > What about

Re: [petsc-dev] Segmentation faults in MatMatMult & MatTransposeMatMult

Pierre Jolivet via petsc-dev writes: > OK, I was wrong about MATAIJ, as Jed already pointed out. > What about BAIJ or Dense matrices? BAIJ (and SBAIJ) is handled by MatXAIJSetPreallocation.

Re: [petsc-dev] Segmentation faults in MatMatMult & MatTransposeMatMult

We should repair the MPI matrix implementations so that this works on communicators of size 1, but why can't you use MatXAIJSetPreallocation(). https://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/Mat/MatXAIJSetPreallocation.html Pierre Jolivet via petsc-dev writes: > Cf. the end of

Re: [petsc-dev] testing code which use partitioners

METIS will use its internal implementation if USE_GKRAND is defined. Maybe other partitioners have similar functionality. I'm not wild about the complexity of providing our own definitions. Note that libmetis.so does not link to libpetsc.so so it would be nontrivial to make that work with both

Re: [petsc-dev] Checkpoint-restart with DMPlex objects

Hapla Vaclav via petsc-dev writes: > So my overall idea (which I presented also at this year's User Meeting > in London and nobody has objected yet), is that some FE codes could > potentially use only this for both checkpointing and > viewing. Advantages would include removing the redundancy in

[petsc-dev] Docker images and NERSC's Shifter

The PETSc and FEniCS Dockerfiles and linked images here might be of interest to anyone running at an HPC facility that supports NERSC's Shifter. https://github.com/jedbrown/jedbrown-dockerfiles IMO, Shifter is far superior to any other HPC deployment mechanism and really should be supported

Re: [petsc-dev] default MPI in debian/ubuntu: openmpi vs mpich

The Open MPI API is better for developers due to better type safety (all handles in MPICH are typedef'd to int). Most major commercial vendors are organized around variants of MPICH (where there is collective ABI standardization). Open MPI is more modular so most vendor stuff goes into their

Re: [petsc-dev] need for HDF5 < 1.8.0 support?

"Smith, Barry F." writes: >> On Dec 7, 2018, at 2:25 PM, Jed Brown wrote: >> >> "Smith, Barry F." writes: >> On Dec 7, 2018, at 8:56 AM, Jed Brown wrote: "Smith, Barry F." writes: > A potential drawback is some users also use HDF5 directly in their code > and

Re: [petsc-dev] need for HDF5 < 1.8.0 support?

"Smith, Barry F." writes: >> On Dec 7, 2018, at 8:56 AM, Jed Brown wrote: >> >> "Smith, Barry F." writes: >> >>> A potential drawback is some users also use HDF5 directly in their code >>> and may be using an older version (people are very slow to change). >> >> The HDF5 developers were

Re: [petsc-dev] need for HDF5 < 1.8.0 support?

"Smith, Barry F." writes: > A potential drawback is some users also use HDF5 directly in their code and > may be using an older version (people are very slow to change). The HDF5 developers were very deliberate about this. You can still use the old API in your own code while linking to the

Re: [petsc-dev] need for HDF5 < 1.8.0 support?

I'm in favor of requiring >=1.8.0. Hapla Vaclav via petsc-dev writes: > I wanted to add support for HDF5 attributes of groups (currently only > datasets). > > But I already feel like held back by supporting HDF5 older than 1.8.0. Do we > still need that? > > My arguments to get rid of that

Re: [petsc-dev] Implementing of a variable block size BILU preconditioner

Ali Reza Khaz'ali writes: > Dear Jed, > > ILU with BAIJ works, and its performance in reducing the condition number is > slightly better than PCVPBJACOBI. Thanks for your guidance. Is it ILU(0)? Did you need to turn enable shifts? Can you write out a small matrix that succeeds with BAIJ/ILU,

<    1   2   3   >