icepack_therm_vertical: add new local variables delt, deltq instead of using worka, workb

[phil-blain]

While comparing CICE6 with CICE4 in the context of my project, I noticed that the variables worka, workb in subroutine icepack_step_therm1 should probably be renamed to delt, deltq (or at least new variables created with these names).

They are declared here:

Icepack/columnphysics/icepack_therm_vertical.F90

Lines 2397 to 2399 in 27b872c

	real (kind=dbl_kind) :: &
	rnslyr , & ! 1 / nslyr
	worka, workb ! temporary variables

And sent to icepack_atm_boundary here:

Icepack/columnphysics/icepack_therm_vertical.F90

Lines 2705 to 2712 in 27b872c

	call icepack_atm_boundary('ice', &
	Tsfc(n), potT, &
	uatm, vatm, &
	wind, zlvl, &
	Qa, rhoa, &
	strairxn, strairyn, &
	Trefn, Qrefn, &
	worka, workb, &

where they are received as the delt and delq arguments:

Icepack/columnphysics/icepack_atmo.F90

Lines 855 to 862 in 27b872c

	subroutine icepack_atm_boundary(sfctype, &
	Tsf, potT, &
	uatm, vatm, &
	wind, zlvl, &
	Qa, rhoa, &
	strx, stry, &
	Tref, Qref, &
	delt, delq, &

I notice writing this that worka and workb are also used in other more recent computations.

Anyway, these names date back to the use of global, temporary work arrays in CICE4 and it would be a good clean up to add new local variables with names delt and delq and pass those to icepack_atm_boundary, I think...

I also noticed the following:

• delt and deltq are marked intent(inout) in icepack_atm_boundary, atmo_boundary_const and atmo_boundary_layer but are really intent(out); their value is not used before being assigned in those subroutines.

[eclare108213]

Changing the names of local variables is fine with me, if it makes the code easier to follow. Reusing work arrays was originally to minimize memory use but we can hardly claim to be efficient with that anymore.

intent(inout) was used to prevent an extra copy when passing arguments in and out of subroutines, and so was used throughout the code for this small bit of computational efficiency gain. For some reason, intent(out) did an extra copy that (inout) didn't have to do. I'm not sure whether this is still an issue with newer compilers. The tradeoff, of course, is some confusion about whether the variable actually needs to be passed in. I used it as a convenient excuse for gathering initializations into one code block in a higher routine.