The dist_fn module is too large and contains too many different things

[David Dickinson]

The dist_fn module is rather large and contains a wide range of different things including:

1. Key calculations of the basic physics properties, velocities etc.
2. The main time advance calculation
3. Flow shear advection
4. Parallel boundary conditions
5. The source terms and related arrays
6. The field equations calculation
7. Moments and related diagnostics.

To make the code more accessible and flexible I propose we split some of this code into other modules.

In particular here I would like to move the moments and related diagnostics and the field equation calculations into their own module. This might have some impact on the planned merging of diagnostics (just in terms of structure).

I propose creating a dist_fn_moments module and a field_equations module.

We might also want to consider splitting things further.

‌

[David Dickinson]

There are 111 subroutines in dist_fn in current next. I think the following 32 could be moved into a dist_fn_moments_and_checks module

1. collision_error
2. dot
3. eexchange
4. estimate_error
5. flux
6. flux_dist
7. flux_vss_e
8. flux_vs_theta_vs_vpa
9. getemoms
10. get_epar
11. get_flux
12. get_flux_dist
13. get_flux_dist
14. get_flux_tormom
15. get_flux_vs_e
16. get_gtran
17. get_heat
18. get_jext
19. get_lfflux
20. get_mom_glm
21. getmoms
22. getmoms_gryfx_dist
23. getmoms_notgc
24. get_parity_conn
25. get_verr
26. get_vnewk
27. init_mom_coeff
28. lf_flux
29. pflux_vs_theta_vs_vpa
30. write_f
31. write_fyx
32. write_poly

The following could be moved into a field_equations module

1. check_getan
2. getan
3. getan_nogath
4. getfieldeq
5. getfieldeq1
6. getfieldeq1_nogath
7. getfieldeq_nogath
8. init_fieldeq

‌

[David Dickinson]

Some issues with moving the field equations code is that it depends on things like the adiabatic option and parallel boundary condition options in places. These currently belong to dist_fn_knobs namelist. Some of these could be relocated (e.g. adiabatic_option and gridfac only used in the field routines in dist_fn), but others, such as the boundary option may be harder to move.

[David Dickinson]

The wdrift_func, wcurv_func and wcoriolis_func routines in dist_fn mostly just depend on the geometry and the grids so would perhaps be more suited to theta_grid However this isn’t possible currently as kt_grids depends on theta_grid and these drift routines depend on kt_grids. Perhaps we could introduce a physics_terms module or similar for gathering things like the drifts, vpar, vperp etc. (i.e. the physics terms built up from our grid choices [theta, kt, species, le]) or break it down further with a module for drifts, one for velocities etc.

‌

[David Dickinson]

It might be worth creating the following small modules:

1. drifts – init_wdrift and related arrays
2. field_equations – gamtot’s, getfieldeq and related
3. time_advance – timeadv (single routine but rather important so worth it?)
4. dist_fn_diagnostics (the moments and checks routines above).
5. invert_rhs – invert_rhs and related routines. This one is perhaps less clear.

‌