# Diffusion granule code walkthrough, 30.1.2023
###### tags: diffusion, icon

[mo_nh_diffusion_new.f90](https://gitlab.dkrz.de/icon/icon-cscs/-/blob/diffusion_granule/src/atm_dyn_iconam/mo_nh_diffusion_new.f90): this is Will's granule

## notes

- GZ: not mixing namelist variables and constants.
- ICON-C modularization team suggested passing constants as arguments to granule_init
- WS: put physical constants into library,
- GZ: could be ok for this
- FP: will generate a lot of discussion whether something is a constant or not.

- GZ: split up t_diffusion into smaller bits, t_diffusion_control, t_diffusion_parameters, (WS: suggests t_diffusion_constants, see above)
- FP: when do you use a pointer and when do you use a value. Only to save copying, or to say "I don't own this" and then also have scalar pointers. WS scalar pointers are dangerous because you don't know whether they are persistent variables.
- GZ: ndyn_substeps is not a constant it can be dynamically adjusted. The timestemp ratio is not necessarily constant. *the one used in diffusion is using the constant ones*
- JB (Joerg Behrens): you need extra information in the input arguments INTEGER, TARGET, INTENT(IN), in order to ensure that the values themselves have the same INTENT. [EDIT(JB): intent(in) for pointer arguments does not protect the target value - only the pointer-target association. Therefore we also need to agree on the intent(in) semantics of the target value.] Convention sufficient?
- JB: your ambition was to minimize module dependencies. Load directly constants, and values that do not change from modules, many pointers supposedly slows down the code.
- GZ/FP: there are many pointers in the ICON code, the CONTIGUOUS keyword addresses that (for some CRAY compiler :-/ ) ML: but CONTIGUOUS inhibits BIND(C)
- GZ: are timings identical? WS will check that.
- JB: is switching input from some other module to diff_inst(jg)% all you did to science code? WS: yes. JB suggests to use FORTRAN ASSOCIATE block, with that we could avoid changes in the physics code (run). But unsure whether this is supported by OPENACC
- FP: in grid manager in favour getter routine, because we could get rid of many fields in t_patch that can simply be calculated on the fly. They could be lazy loaded.
- FP: pointer lifetime: can you check / measure the pointer lifetime? WS: no, I don't know. JB: we assume a sensible workflow.
- GZ: itype_comm is obsolete. it can be removed.