CESM-Development / cime

Common Infrastructure for Modeling the Earth
Other
16 stars 13 forks source link

CLM source code gets rebuilt even if nothing changed #223

Closed billsacks closed 9 years ago

billsacks commented 9 years ago

I don't know if this is a CLM bug or a CIME bug, but I'll file it as a CIME bug for now.

I have noticed that, if you build a test involving CLM (e.g., SMS_D_Ld3.f10_f10.ICLM45BGCCROP.yellowstone_intel), then rebuild without changing anything, at least some of the CLM source files get rebuilt. So, while the builds for other components happen almost instantly, the CLM rebuild takes about 40 seconds.

billsacks commented 9 years ago

cc @jedwards4b @mvertens @ekluzek @bandre-ucar

billsacks commented 9 years ago

Some more information on this:

I have reproduced it from r74030 (I believe) of https://svn-ccsm-models.cgd.ucar.edu/clm2/branches/initinterp_vertical. This is basically clm4_5_3_r136, with a few changes that I don't expect to have affected this bug. It uses cime4.0.1.

I created this test:

SMS_D_Ld3.f10_f10.ICLM45BGCCROP.yellowstone_intel

built it, then rebuilt it without changing anything. In the second build, the CLM build took 46 seconds.

The rebuild began with:

src/main/column_varcon.F90

which has these dependencies (in Depends):

column_varcon.o : clm_varpar.mod shr_assert_mod.mod landunit_varcon.mod ncdio_pio.mod

Jim's hypothesis is that the dependence on shr_assert, which comes in through this include line:

include "shr_assert.h"

is causing the rebuild.

jedwards4b commented 9 years ago

Fixed with #225

rljacob commented 8 years ago

Do you think any cpp commands in file might trigger a re-compile-always? We're finding that files with #ifdef get recompiled even if nothing changes.

ekluzek commented 8 years ago

Hi Rob

Is this for CLM40 or CLM45 code?

We don't have very many #ifdef's in CLM anymore. I only see three files with #ifdefs, even in clm40 code.

clm40 code does have dependency on CPP token settings which it does put in a file. If that's put into the dependency chain that could cause the behavior you are talking about. But, it should be for everything.

For clm45 we now build it in a shared library and reduce the times you have to rebuild it as we've eliminated most CPP switches in favor of run-time logical variables.

Could you show an example of the compiler line where a file is recompiled when it shouldn't have been?

Erik Kluzek, (CGD at NCAR)

National Center for Atmospheric Research

Boulder CO,

(off) (303)497-1326 (fax) (303)497-1348

(skype) ekluzek (cell) (303)859-0183

Pronouns: he/his/him

------------------ Home page ------------------------

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

On Tue, Dec 8, 2015 at 5:50 PM, Robert Jacob notifications@github.com wrote:

Do you think any cpp commands in file might trigger a re-compile-always? We're finding that files with #ifdef get recompiled even if nothing changes.

— Reply to this email directly or view it on GitHub https://github.com/CESM-Development/cime/issues/223#issuecomment-163071697 .

rljacob commented 8 years ago

cc'ing @bishtgautam who may have an example.

bishtgautam commented 8 years ago

CLM45 doesn't have CPP tokens, but ALMv1 does. New physics added in ALMv1 requires PETSc and at present that new physics is protected by #ifdef USE_PETSC_LIB.

jedwards4b commented 8 years ago

Do you have new #include statements? shr_assert.h is treated as a special case in the cime mkDepends script, if you have other #include files you may need to generalize this or add them to the special cases.

On Wed, Dec 9, 2015 at 9:22 PM, Gautam Bisht notifications@github.com wrote:

CLM45 doesn't have CPP tokens, but ALMv1 does. New physics added in ALMv1 requires PETSc and at present that new physics is protected by #ifdef USE_PETSC_LIB.

— Reply to this email directly or view it on GitHub https://github.com/CESM-Development/cime/issues/223#issuecomment-163484375 .

Jim Edwards

CESM Software Engineer National Center for Atmospheric Research Boulder, CO

bishtgautam commented 8 years ago

Yes, there are #include statements for PETSc. For e.g.

!++++++++++++++++++++++++++++++++++++++++
#ifdef USE_PETSC_LIB
module FooType
  ! !PUBLIC TYPES:
  implicit none
  private
#include "finclude/petscsys.h"
#include "finclude/petscvec.h"
#include "finclude/petscvec.h90"
#include "finclude/petscmat.h"
#include "finclude/petscmat.h90"
#include "finclude/petscts.h"
#include "finclude/petscts.h90"
#include "finclude/petscdm.h"
#include "finclude/petscdm.h90"
#include "finclude/petscdmda.h"
#include "finclude/petscdmda.h90"
#include "finclude/petscviewer.h"
  type, public :: foo_type
   ...
   contains
  end type foo_type
end module FooType
!++++++++++++++++++++++++++++++++++++++++