> On Aug 20, 2022, at 12:51 PM, Blaise Bourdin <bour...@mcmaster.ca> wrote: > > > >> On Aug 19, 2022, at 3:59 PM, Barry Smith <bsm...@petsc.dev >> <mailto:bsm...@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 <bour...@mcmaster.ca >>> <mailto:bour...@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
