Re: [petsc-dev] CHKERRQ vs PetscCall for Fortran? Which is the future?

> PetscCall in C doesn’t actually “call” the function that is in its arguments, > but rather “checks” the called function’s return The most logical form would have been `PetscCheck()` but we unfortunately we had just recently added it as a replacement for ``` if (error) SETERRQ() ``` So the

Re: [petsc-dev] CHKERRQ vs PetscCall for Fortran? Which is the future?

> On Apr 26, 2022, at 8:12 PM, Barry Smith wrote: > > I didn't like PetscCall(ierr) in Fortran because it is strange, even > freakish. PetscCall(AFunction(args)) makes sense in C but IMHO "call > AFunction(args,ierr); PetscCall(ierr)" looks weird, what are you calling? > Nothing. I'd like to

Re: [petsc-dev] CHKERRQ vs PetscCall for Fortran? Which is the future?

I didn't like PetscCall(ierr) in Fortran because it is strange, even freakish. PetscCall(AFunction(args)) makes sense in C but IMHO "call AFunction(args,ierr); PetscCall(ierr)" looks weird, what are you calling? Nothing. I'd like to keep CHKERRQ(ierr) in Fortran and not support PetscCall(i

Re: [petsc-dev] odd log behavior

> On Apr 26, 2022, at 6:40 PM, Matthew Knepley wrote: > > On Tue, Apr 26, 2022 at 6:12 PM Justin Chang > wrote: > I think N/A (not applicable) would be a better message than NaN. Prior to > this mail, even I thought I broke something with these NaN's > > We would

Re: [petsc-dev] odd log behavior

The current nan output has to be replaced to get the column alignment correct, I just didn't feel like making that change also in the same MR. Something like Unknown or anything that fits in the column space would be fine. It just means for the given run the timing numbers are not meaning

Re: [petsc-dev] CHKERRQ vs PetscCall for Fortran? Which is the future?

Hm we reverted all fortran examples to use CHKERRQ(). [from PetscCall] so presumably CHKERRQ() is still the preferred interface from fortran? Satish On Tue, 26 Apr 2022, Jacob Faibussowitsch wrote: > Hi Glenn, > > `PetscCall()` is the future, apologies for the confusion. > > `CHKERRQ()` was m

Re: [petsc-dev] CHKERRQ vs PetscCall for Fortran? Which is the future?

Hi Glenn, `PetscCall()` is the future, apologies for the confusion. `CHKERRQ()` was mistakenly deleted from the fortran include files but exists for backwards-compatibility only. Unlike “normal” changes we opted not to formally deprecate `CHKERRQ()` and friends (complete with compiler warnings

Re: [petsc-dev] CHKERRQ vs PetscCall for Fortran? Which is the future?

On Tue, Apr 26, 2022 at 6:43 PM Hammond, Glenn E via petsc-dev < petsc-dev@mcs.anl.gov> wrote: > PETSc, > > I see that CHKERRQ is back in the Fortran interface after 3.17.1. Will > CHKERRQ be removed in the future? I just wrote a script to refactor > PFLOTRAN [CHKERRQ() -> PetscCall()], and I wa

[petsc-dev] CHKERRQ vs PetscCall for Fortran? Which is the future?

PETSc, I see that CHKERRQ is back in the Fortran interface after 3.17.1. Will CHKERRQ be removed in the future? I just wrote a script to refactor PFLOTRAN [CHKERRQ() -> PetscCall()], and I want to know which direction to head before asking everything to check in all their dev branches. If CH

Re: [petsc-dev] odd log behavior

On Tue, Apr 26, 2022 at 6:12 PM Justin Chang wrote: > I think N/A (not applicable) would be a better message than NaN. Prior to > this mail, even I thought I broke something with these NaN's > We would need some logic to check for NaN and change the format. Matt > On Tue, Apr 26, 2022 at 2

Re: [petsc-dev] odd log behavior

I think N/A (not applicable) would be a better message than NaN. Prior to this mail, even I thought I broke something with these NaN's On Tue, Apr 26, 2022 at 2:49 PM Matthew Knepley wrote: > On Tue, Apr 26, 2022 at 12:03 PM Mark Adams wrote: > >> Well, Nans are a clear sign that something is v

Re: [petsc-dev] odd log behavior

On Tue, Apr 26, 2022 at 12:03 PM Mark Adams wrote: > Well, Nans are a clear sign that something is very wrong. > Barry chose them so that it could not be mistaken for an actual number. Matt > On Tue, Apr 26, 2022 at 11:52 AM Jacob Faibussowitsch > wrote: > >> There is an automatic warning

Re: [petsc-dev] odd log behavior

Well, Nans are a clear sign that something is very wrong. On Tue, Apr 26, 2022 at 11:52 AM Jacob Faibussowitsch wrote: > There is an automatic warning that shows when you do run with > `-log_view_gpu_time`, but perhaps there should also be an automatic warning > when *not* running with it. It is

Re: [petsc-dev] odd log behavior

There is an automatic warning that shows when you do run with `-log_view_gpu_time`, but perhaps there should also be an automatic warning when *not* running with it. It is unfortunate that NaN is the value printed as this implies a bug but AFAIK it is unavoidable (Barry can say more on this tho

Re: [petsc-dev] odd log behavior

You have to add -log_view_gpu_time See https://gitlab.com/petsc/petsc/-/merge_requests/5056 Jose > El 26 abr 2022, a las 16:39, Mark Adams escribió: > > I'm seeing this on Perlmutter with Kokkos-CUDA. Nans in most log timing data > except the two 'Solve' lines. > Just cg/jacobi on snes/ex56.

[petsc-dev] odd log behavior

I'm seeing this on Perlmutter with Kokkos-CUDA. Nans in most log timing data except the two 'Solve' lines. Just cg/jacobi on snes/ex56. Any ideas? VecTDot2 1.0 nan nan 1.20e+01 1.0 0.0e+00 0.0e+00 0.0e+00 0 0 0 0 0 0 0 0 0 0 -nan-nan 0 0.00e+000 0.00e+00