Hi Barry,
That was a good question, and I didn’t know the answer but I did a little
digging, and in fact, in the 2018 Fortran standard, an extended form of
implicit none was introduced that disable also implicit procedures:
implicit none (type, external)
Indeed, when adding that to the little
implicit none prevents using undeclared variables. Is there a way to avoid
calling any functions/suboutines that don't have an interface declared in a
module? That would have found this problem.
Barry
> On Jun 22, 2025, at 8:06 PM, Randall Mackie wrote:
>
> Thanks Barry!
>
>
>
>> On
Thanks Barry!
> On Jun 22, 2025, at 4:50 PM, Barry Smith wrote:
>
>
>I'm sorry for not getting back to you sooner. I have attached a working
> version of your code. Since you were missing
>
> use petscdmcomposite
>
> the compiler could not generate the correct call to DMCompositeGet
I'm sorry for not getting back to you sooner. I have attached a working version of your code. Since you were missing use petscdmcompositethe compiler could not generate the correct call to DMCompositeGetGlobalISs() Barry
test.F90
Description: Binary data
On Jun 17, 2025, at 6:39 PM, Randall
Dear PETSc,
On Tuesday I sent a small reproducer program that shows a problem with the
Fortran version of DMCompositeGetGlobalISs, with the valgrind stack trace below.
Not having yet received a reply, I’m just wondering if perhaps my email slipped
through the cracks.
Would appreciate some guid
Follow up: running with valgrind shows the following issues….is this a bug in
PETSc?
==5216== Use of uninitialised value of size 8
==5216==at 0x49ED69C: f90array1dcreatefortranaddr_ (f90_fwrap.F90:52)
==5216==by 0x4D7EA94: F90Array1dCreate (f90_cwrap.c:140)
==5216==by 0x6B7295A: dmcom
Dear Petsc users -I am trying to upgrade my code to petsc-3.23 (from 3.19), and I seem to have run into a problem with DMCompositeGetGlobalISs.The example program listed on the man page for DMCompositeGetGlobalISs, https://petsc.org/release/src/snes/tutorials/ex73f90t.F90.html, seems to indicate th
