[petsc-dev] Type mismatch warnings

Barry Smith bsmith at petsc.dev
Sat Aug 20 12:23:17 CDT 2022



> On Aug 20, 2022, at 12:51 PM, Blaise Bourdin <bourdin at mcmaster.ca> wrote:
> 
> 
> 
>> On Aug 19, 2022, at 3:59 PM, Barry Smith <bsmith at petsc.dev <mailto:bsmith at petsc.dev>> wrote:
>> 
>> 
>> 
>> 
>> I think the two solutions are
>> 
>> 1)  to have an interface for each object type (they could possibly all call the same fortran stub function (that won't have an interface definition so that the call inside the interface (for each object type) won't issue an error or warning. 
> 
> That would be the right thing to do. If there is a small number of functions that take a petscobject as argument, I can write the specific and generic interfaces. If we wanted all PetscObjectXXX functions, this would need to be automated

Simple python script that loops over PetscObjects and loops over methods; methods could include XXXSetType(), XXXDestroy(). XXXSetFromOptions(), etc. The complication is different objects results belong in different files, the pattern might be

src/YYY/f90-mod/petscXXX_standard.h90  (where  somehow YYY it is figured out automatically from the file or directory XXX is defined in)

With a little more work, things like XXXView() (that take additional arguments) could also be generated automatically.

With yet a little more work the actual Fortran stub functions for many of the xxxmethod_() could be generated automatically.

This would be cool, we could strip out a bunch of manually written and maintained Fortran interface stuff and not have to add them for each new PetscObject that Matt introduces (saving you work :-)).

I can help you with this

>> 
>> 2) there is a way to use a * (I forgot the exact syntax in an interface to indicate anything can be pass through that variable) but it is not in Fortran 95 (I'm not sure when it was introduced) so it may not be portable enough.
> 
> This whole process is a real mess anyway. Not any variable can be passed as a polymorphic pointer because it would be too simple. Perhaps we could have petscobject be a class and all other objects subclasses of petscobject. Or make foretran types C interoperable and pass their address using c_loc
> What is the older compiler / standard we are targetting?

  Probably PETSc future :-) Fortran bindings. We don't have an official minimum but I think going above 1995 is risky and would prefer not to use Fortran constructs like classes in our current bindings.

> 
> Blaise
> 
>> 
>> Barry
>> 
>>> On Aug 19, 2022, at 1:34 PM, Blaise Bourdin <bourdin at mcmaster.ca <mailto:bourdin at mcmaster.ca>> wrote:
>>> 
>>> Hi,
>>> 
>>> Does anybody know if there is a magic gfortran flag to get rid of type mismatch warnings?
>>> These pop up when using PetscObjectSetName with two different petsc objects, for instance.
>>> 
>>> Warning: Type mismatch between actual argument at (1) and actual argument at (2) (TYPE(tdm)/TYPE(tpetscsf)).
>>> 
>>> Regards,
>>> Blaise
>>> 
>>>>>> Tier 1 Canada Research Chair in Mathematical and Computational Aspects of Solid Mechanics
>>> Professor, Department of Mathematics & Statistics
>>> Hamilton Hall room 409A, McMaster University
>>> 1280 Main Street West, Hamilton, Ontario L8S 4K1, Canada 
>>> https://www.math.mcmaster.ca/bourdin <https://www.math.mcmaster.ca/bourdin> | +1 (905) 525 9140 ext. 27243
>>> 
>> 
> 
>> Tier 1 Canada Research Chair in Mathematical and Computational Aspects of Solid Mechanics
> Professor, Department of Mathematics & Statistics
> Hamilton Hall room 409A, McMaster University
> 1280 Main Street West, Hamilton, Ontario L8S 4K1, Canada 
> https://www.math.mcmaster.ca/bourdin <https://www.math.mcmaster.ca/bourdin> | +1 (905) 525 9140 ext. 27243

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20220820/e3d75431/attachment.html>


More information about the petsc-dev mailing list