|
| 1 | +# GitHub Copilot Instructions – Pull-Request Reviews for MFC |
| 2 | + |
| 3 | +These instructions guide **GitHub Copilot Code Review** and **Copilot Chat** when they evaluate pull requests in this repository. |
| 4 | + |
| 5 | +--- |
| 6 | + |
| 7 | +## 1 Project Context (always include) |
| 8 | + |
| 9 | +* **Project:** MFC (exascale many-physics solver) written in **modern Fortran 2008+**, generated with **Fypp**. |
| 10 | +* **Directory layout:** |
| 11 | + * Sources in `src/`, tests in `tests/`, examples in `examples/`. |
| 12 | + * Most source files are templated `.fpp`; CMake transpiles them to `.f90`. |
| 13 | +* **Fypp macros** are in `src/<subprogram>/include/`, where `<subprogram>` is `simulation`, `common`, `pre_process`, or `post_process`. Review these first. |
| 14 | +* Only `simulation` (plus its `common` dependencies) is GPU-accelerated with **OpenACC**. |
| 15 | + |
| 16 | +> **Copilot, when reviewing:** |
| 17 | +> * Treat the codebase as free-form Fortran 2008+ with `implicit none`, explicit `intent`, and standard intrinsics. |
| 18 | +> * Prefer `module … contains … subroutine foo()` over legacy constructs; flag uses of `COMMON`, file-level `include`, or other global state. |
| 19 | +
|
| 20 | +--- |
| 21 | + |
| 22 | +## 2 Incremental-Change Workflow |
| 23 | + |
| 24 | +Copilot, when reviewing: |
| 25 | +* Encourage small, buildable commits |
| 26 | + |
| 27 | +--- |
| 28 | + |
| 29 | +## 3 Style & Naming Conventions (*.fpp / *.f90) |
| 30 | + |
| 31 | +| Element | Rule | |
| 32 | +|---------|------| |
| 33 | +| Indentation | 2 spaces; continuation lines align beneath &. | |
| 34 | +| Case | Lower-case keywords & intrinsics (do, end subroutine, …). | |
| 35 | +| Modules | m_<feature> (e.g. m_transport). | |
| 36 | +| Public subroutines | s_<verb>_<noun> (s_compute_flux). | |
| 37 | +| Public functions | f_<verb>_<noun>. | |
| 38 | +| Routine size | subroutine ≤ 500 lines, helper ≤ 150, function ≤ 100, file ≤ 1000. | |
| 39 | +| Arguments | ≤ 6; else use a derived-type params struct. | |
| 40 | +| Forbidden | goto (except legacy), COMMON, save globals. | |
| 41 | +| Variables | Every arg has explicit intent; use dimension/allocatable/pointer as appropriate. | |
| 42 | +| Errors | Call s_mpi_abort(<msg>), never stop or error stop. | |
| 43 | + |
| 44 | +Copilot, when reviewing: |
| 45 | +* Flag violations of any cell above. |
| 46 | +* Suggest refactors when size or argument limits are exceeded. |
| 47 | +* Ensure private helpers stay inside their defining module and avoid nested procedures. |
| 48 | + |
| 49 | +--- |
| 50 | + |
| 51 | +## 4 OpenACC Guidelines (for GPU kernels) |
| 52 | + |
| 53 | +Wrap tight loops: |
| 54 | + |
| 55 | +```fortran |
| 56 | +!$acc parallel loop gang vector default(present) reduction(...) |
| 57 | +``` |
| 58 | + |
| 59 | +* Add collapse(n) when safe. |
| 60 | +* Declare loop-local variables with private(...). |
| 61 | +* Allocate large arrays with managed or move them into a persistent !$acc enter data region at start-up. |
| 62 | +* Avoid stop/error stop inside device code. |
| 63 | +* Code must compile with Cray ftn, NVIDIA nvfortran, GNU gfortran, and Intel ifx/ifort. |
| 64 | + |
| 65 | +--- |
| 66 | + |
| 67 | +## 5 Review Checklist (what Copilot should verify) |
| 68 | + |
| 69 | +1. Buildability: PR includes build instructions or CI passes the staged build. |
| 70 | +2. Tests: Focused tests are added/updated. |
| 71 | +3. Style compliance: All rules in §3 are satisfied. |
| 72 | +4. Module hygiene: No new global state; proper namespacing. |
| 73 | +5. Performance: GPU code follows §4; no large host/device transfers in hot loops. |
| 74 | +6. Documentation: Updated in-code comments and, when needed, README or docs site. |
| 75 | +7. Regressions: No changes to outputs of golden tests without clear justification. |
0 commit comments