search

stfc / PSyclone

Domain-specific compiler and code transformation system for Finite Difference/Volume/Element Earth-system models in Fortran
BSD 3-Clause "New" or "Revised" License
104 stars 28 forks source link

Generate API-conformant code #358

Open TeranIvy opened 5 years ago

TeranIvy commented 5 years ago

Each of the APIs supported by PSyclone has its own coding standards. There is no general agreement on whether PSyclone should generate API-conformant code. This issue discusses

  1. Whether it would be useful to have API-conformance as a rule for code generation in specific API and
  2. What rule to follow in case of transforming the model code to a different language (e.g. rewriting kernels from Fortran to C), as there are usually only coding standards for the original language.
TeranIvy commented 5 years ago

My opinion on these two points is below.

  1. Yes, it would be useful to generate code that adheres to the coding standards of the Earth System model that the API supports.
  2. It would be good to check with the model developers about existing practices of writing in another language. If there are no coding standards for another language then it would be useful to set standards in PSyclone.
hiker commented 5 years ago

Imho I don't see a particular reason to adhere to a coding standard - e.g. in my case the Fortran files created by psyclone are contained in the build directory only. The only advantage I could see would be for debugging, you could see 'more familiar' code, but imho this would not justify the effort that would be required.

rupertford commented 5 years ago

In general an API should support more than one code. I appreciate that this is not the case for dynamo0p3/LFRic at the moment but it is possible for some other non-LFRic code to use the same API. Therefore I don't think PSyclone code that is generated and/or modified for a particular API should necessarily follow the convention of a particular code.

I also think that, as @hiker says, the generated code will not (and should not) be seen by scientists in normal circumstances.

However, I do agree that, when there are errors, the nicer the generated code is, the easier it is to read.

For the dynamo0.3 (LFRic) API in particular, I think we should raise it at the next LFRic telco. If it is agreed that it would be useful to adhere to coding standard rules then we can start making appropriate changes to the code generation. However, I do think this could be difficult to conform to, as a lot of formatting is based on the output of the parser and there is currently no way to control this formatting. In cases like choosing == over .eq., it shouldn't be difficult to make changes.