Perhaps:
#define XXXF90() XXX()
Eventhough it won't give deprecated message to user - it will get the code
compiling. [and these routines don't need to go away]
Satish
On Sun, 23 Mar 2025, Barry Smith wrote:
>
>With the update for the Fortran binding all the XXXF90 routines have been
Barry and Jose,
I have gotten my compile issues down to the following:
usolve.F:84:46:
84 | MatInfo info(MAT_INFO_SIZE)
| 1
Error: Symbol 'mat_info_size' at (1) has no IMPLICIT type; did you
mean 'mpi_win_size'?
If you look at the top500 list, 50% of the machines have Infiniband and 37%
Gigabit Ethernet. InfiniBand has a low latency of 3–5 microseconds, which is
much lower than Ethernet's 20–80 microseconds. But Ethernet can be a
cost-effective solution with reasonably good performance, provided that yo
Perfect, that seems to have fixed the issue.
Thanks for your help!
Steven
On Thu, 3 Apr 2025 at 04:52, Junchao Zhang wrote:
> Hi, Steven,
>Thanks for the test, which helped me easily find the petsc bug. I have
> a fix at
> https://urldefense.us/v3/__https://gitlab.com/petsc/petsc/-/merge_
We have worked on semi coarsening in DMPlex, but it is not finished and we
are not working on it now.
I'm not sure about how easy it would be in DMDA, but Barry is suggesting
that it is doable.
We need to wait for Matt and he is on travel so his response may be delayed.
Mark
On Thu, Mar 20, 202
PETSc 2.23 introduced some incompatibilities in the Fortran bindings with
previous versions of PETSc.
As part of upgrading Fortran code for use with PETSc 2.23 the suffix F90
should be removed from all PETSc Fortran calls; for routines such as
DMDAVecGetArrayF90() no other changes are
