Remove unused variables

[bartnijssen]

Removal of unused variables cuts down on compiler warnings. That way we can figure out which compiler warnings are meaningful. Many of the unused variables have to do with associate statements that were introduced by Martyn. Others are simply never used.

[bartnijssen]

This pull request is complete. There are unused variables left in a few files:

• soilLiqFlx.f90
• coupled_em.f90
• layerMerge.f90
• layerDivide.f90
• systemSolv.f90

But these need to be gone through carefully. If you are fine with the changes here, just go ahead and merge

[martynpclark]

Opening up a new issue for an alternative method to compute thermal conductivity of soils

[bartnijssen]

But the point is that in the code that is distributed we should either implement it fully (as an option) or leave it out. You can have many branches in your own repo @ martynpclark/summa with work in progress, but that should not be part of the release summa version. My concern is that this quickly becomes intractable. People assume that they can uncomment the code and that it works, which may not be the case. Git does not care if you have 100's of branches.

I know git is frustrating in the beginning, but now that I am finally getting the hang of it, I think that is exactly how we should do it. Keep in mind that once we open the repo, our own repos will also be accessible to others, so we can always point collaborators to our own branches that may have special features. By necessity, the released version of SUMMA will always be a little behind the cutting edge (but it will be clean and stable).

[martynpclark]

OK. I get it.

As an alternative can we open up a new issue and include the commented code
as part of the issue description?

Cheers
M.
On May 18, 2015 4:53 PM, "Bart Nijssen" notifications@github.com wrote:

In build/source/engine/diagn_evar.f90
#49 (comment):

@@ -244,12 +215,6 @@ subroutine diagn_evar(&
! iLayer, mLayerVolFracIce(iLayer), mLayerVolFracLiq(iLayer), mLayerThermalC(iLayer)

 endif

• ! compute the thermal conductivity of the wet material (W m-1)
• !lambda_wet = lambda_wetsoil**(1._dp - theta_sat) * lambda_watertheta_sat * lambda_ice(theta_sat - mLayerVolFracLiq(iLayer))
• ! compute the Kersten number (-)
• !kerstenNum = log10( (mLayerVolFracIce(iLayer) + mLayerVolFracLiq(iLayer))/theta_sat ) + 1._dp
• ! ...and, compute the thermal conductivity
• !mLayerThermalC(iLayer) = kerstenNum_lambda_wet + (1._dp - kerstenNum)_lambda_drysoil

But the point is that in the code that is distributed we should either
implement it fully (as an option) or leave it out. You can have many
branches in your own repo @ martynpclark/summa with work in progress, but
that should not be part of the release summa version. My concern is that
this quickly becomes intractable. People assume that they can uncomment the
code and that it works, which may not be the case. Git does not care if you
have 100's of branches.

I know git is frustrating in the beginning, but now that I am finally
getting the hang of it, I think that is exactly how we should do it. Keep
in mind that once we open the repo, our own repos will also be accessible
to others, so we can always point collaborators to our own branches that
may have special features. By necessity, the released version of SUMMA will
always be a little behind the cutting edge (but it will be clean and
stable).

—
Reply to this email directly or view it on GitHub
https://github.com/UCAR/summa/pull/49/files#r30555197.