[MITgcm-devel] testreport again

Jean-Michel Campin jmc at ocean.mit.edu
Tue Apr 14 20:26:41 EDT 2015 

Hi Martin,

I am fine with your suggestion to change the way FEXTRAFLAGS 
is applied (it might not be beautiful, but if this helps).

Cheers,
Jean-Michel

On Wed, Apr 08, 2015 at 09:02:05AM +0200, Martin Losch wrote:
> Hi Oliver, Jean-Michel,
> 
> that sounds awfully convoluted (and having a target ???small_f??? that does actually more than produce only ???small f files??? is a bit inconsistent), but I think I???ll have different, maybe simpler, solution for my problem:
> 
> As far as I can see there are only two files affected: ptracers_dyn_state_data_mod.F  ptracers_dyn_state_mod.F
> With your consent I can append the content of  ???FEXTRAFLAG???, which I introduced only because of inlining anyway, to FOPTIM (line 2905 in genmake2) rather than FFLAGS (line 2904 in genmake2), and then I put the above files into the NOOPTFILES list in my specific options file. That way these files don???t see the FEXTRAFLAGS. 
> 
> The purpose of FEXTRAFLAGS was to add specific optimization options, that would make the simple tests in genmake2 fail for the wrong reason.
> 
> Does that sound good to you?
> 
> Martin
> 
> > On 07 Apr 2015, at 21:29, Oliver Jahn <jahn at mit.edu> wrote:
> > 
> > Hi Martin,
> > 
> > short answer: what's different is that ptracers uses Fortran 90 modules.
> > 
> > long answer: at the "make depend" stage, tools/f90mkdepend generates
> > dependencies that make sure modules are compiled before files that use
> > them.  The proper way to do this would be to find all object files that
> > need these modules and add dependencies for these object files.  What
> > f90mkdepend actually does is to make the preprocessed source files and
> > headers that have use statements in them depend on the object files of
> > the modules.  That means modules need to be compiled at the
> > preprocessing stage.  I think for fortran files with use statements, one
> > could just replace the .f with .o in the generated dependency (but maybe
> > I am missing a reason for why it was done this way).
> > 
> > Unfortunately somebody (ahem) has put use statements in header files.
> > For these one would have to find the fortran files that include these
> > headers (could be extracted from the Makefile at the time f90mkdepend
> > runs) in order to put the correct object files in the dependency.  I can
> > have a look at how to do this when I find the time.
> > 
> > Alternatively, as Jean-Michel points out, one could put the module files
> > in the dependency and generate these without creating object files (at
> > least some compilers are capable of this) before the preprocessing stage.
> > 
> > Cheers,
> > Oliver
> > 
> > On 2015-04-07 11:42, Martin Losch wrote:
> >> Hi Jean-Michel, Oliver,
> >> 
> >> the new flag for testreport, that I just checked in works fine with all experiments, except for the ones that compile ptracers, e.g.
> >> e.g., cfc_example, exp4, global_ocean.90x40x15. The reason is that ???make small_f??? does not work properly, eg. in global_ocean_ebm I get this:
> >> 
> >>>>> make small_f
> >> [???]
> >> cat monitor_ad.F |  /lib/cpp -traditional -P -DTARGET_NEC_SX -DWORDLENGTH=1 -DHAVE_CLOC -UHAVE_SIGREG -DSEAICE_VECTORIZE_LSR -DSEAICE_VECTORIZE_LSR_ZEBRA -DCG2D_OUTERLOOPITERS=10 -DCG3D_OUTERLOOPITERS=10 -DALLOW_USE_MPI -DHAVE_SYSTEM -DHAVE_FDATE -DHAVE_ETIME -DHAVE_SETRLSTK -DHAVE_STAT -DHAVE_NETCDF -DHAVE_FLUSH  -I/SX/usr/include -I/home/repo/nodes/netcdf/3.6.1_32_dw/SX/include -I/SX/opt/mpisx/LC110002/include | ../../../tools/set64bitConst.sh  > monitor_ad.f
> >> cat monitor_g.F |  /lib/cpp -traditional -P -DTARGET_NEC_SX -DWORDLENGTH=1 -DHAVE_CLOC -UHAVE_SIGREG -DSEAICE_VECTORIZE_LSR -DSEAICE_VECTORIZE_LSR_ZEBRA -DCG2D_OUTERLOOPITERS=10 -DCG3D_OUTERLOOPITERS=10 -DALLOW_USE_MPI -DHAVE_SYSTEM -DHAVE_FDATE -DHAVE_ETIME -DHAVE_SETRLSTK -DHAVE_STAT -DHAVE_NETCDF -DHAVE_FLUSH  -I/SX/usr/include -I/home/repo/nodes/netcdf/3.6.1_32_dw/SX/include -I/SX/opt/mpisx/LC110002/include | ../../../tools/set64bitConst.sh  > monitor_g.f
> >> cat ptracers_ad_dump.F |  /lib/cpp -traditional -P -DTARGET_NEC_SX -DWORDLENGTH=1 -DHAVE_CLOC -UHAVE_SIGREG -DSEAICE_VECTORIZE_LSR -DSEAICE_VECTORIZE_LSR_ZEBRA -DCG2D_OUTERLOOPITERS=10 -DCG3D_OUTERLOOPITERS=10 -DALLOW_USE_MPI -DHAVE_SYSTEM -DHAVE_FDATE -DHAVE_ETIME -DHAVE_SETRLSTK -DHAVE_STAT -DHAVE_NETCDF -DHAVE_FLUSH  -I/SX/usr/include -I/home/repo/nodes/netcdf/3.6.1_32_dw/SX/include -I/SX/opt/mpisx/LC110002/include | ../../../tools/set64bitConst.sh  > ptracers_ad_dump.f
> >> sxmpif90 -Pstack -sxace -pi -pi auto fullmsg exp=barrier,ucase,timestep_tracer,ilnblnk,ifnblnk,cycle_tracer,pressure_for_eos,sw_temp,sw_ptmp,gsw_pt_from_ct rexp=fool_the_compiler,fool_the_compiler_r8,bar2,sw_adtg,gsw_ct_from_pt,gsw_gibbs_pt0_pt0 expin=barrier.f,timestep_tracer.f,fool_the_compiler.f,bar2.f,utils.f,cycle_tracer.f,pressure_for_eos.f,seawater.f,gsw_teos10.f -C vsafe -c ptracers_dyn_state_mod.f
> >> sxf90 fatal : File could not open : barrier.f
> >> make: *** [ptracers_dyn_state_mod.o] Error 1
> >> 
> >> Why is the fortran compiler (sxmpif90) called for ptracers_dyn_state_mod.f when I do ???make small_f???? What???s different for this package?
> >> 
> >> Do you have any clue?
> >> 
> >> Martin
> >> 
> >>> On 07 Apr 2015, at 15:22, Jean-Michel Campin <jmc at ocean.mit.edu> wrote:
> >>> 
> >>> Hi Martin,
> >>> 
> >>> New option name "-small_f" sounds good to me.
> >>> 
> >>> Cheers,
> >>> Jean-Michel
> >>> 
> >>> On Tue, Apr 07, 2015 at 11:58:32AM +0200, Martin Losch wrote:
> >>>> Hi Jean-Michel,
> >>>> 
> >>>> I can try to implement such an option. What do you suggest for a name? ???-small_f??? (already long, but ???-explict_small_f??? is even longer).
> >>>> 
> >>>> Martin
> >>>> 
> >>>>> On 24 Mar 2015, at 15:08, Jean-Michel Campin <jmc at ocean.mit.edu> wrote:
> >>>>> 
> >>>>> Hi Martin,
> >>>>> 
> >>>>> I would prefer to keep the testreport built as close as possible
> >>>>> to the "normal" built, so that we really "test" experiments in
> >>>>> the same conditions.
> >>>>> The other thing is that I am not sure if this "small_f" target will fix completly
> >>>>> the inlining issue for AD and OAD built, but it does not matter too much.
> >>>>> 
> >>>>> What about adding a new option to testreport that would go through this
> >>>>> intermediate "samll_f" step ?
> >>>>> 
> >>>>> Cheers,
> >>>>> Jean-Michel
> >>>>> 
> >>>>> On Tue, Mar 24, 2015 at 01:22:03PM +0100, Martin Losch wrote:
> >>>>>> Hi there,
> >>>>>> 
> >>>>>> do you think we can modify the build procedure for testreport? I.e. in
> >>>>>> makemodel()
> >>>>>> replace 
> >>>>>> 	    $MAKE_CMD $TARG >> make.tr_log 2>&1
> >>>>>> by
> >>>>>> 	    $MAKE_CMD small_f >> make.tr_log 2>&1
> >>>>>> 	    $MAKE_CMD $TARG >> make.tr_log 2>&1
> >>>>>> 
> >>>>>> On my vector computer (we have a new one!), explicit inlining only works if ***all*** ???small_f" files are availabe when the compiler is called, and just doing ???make??? does not work. Can we find a solution for this? Alternatively I have turn off explicit inlining for the tests, which I would like to avoid.
> >>>>>> 
> >>>>>> Martin
> >>>>>> 
> >>>>>> 
> >>>>>> _______________________________________________
> >>>>>> MITgcm-devel mailing list
> >>>>>> MITgcm-devel at mitgcm.org
> >>>>>> http://mitgcm.org/mailman/listinfo/mitgcm-devel
> >>>>> 
> >>>>> _______________________________________________
> >>>>> MITgcm-devel mailing list
> >>>>> MITgcm-devel at mitgcm.org
> >>>>> http://mitgcm.org/mailman/listinfo/mitgcm-devel
> >>>> 
> >>>> 
> >>>> _______________________________________________
> >>>> MITgcm-devel mailing list
> >>>> MITgcm-devel at mitgcm.org
> >>>> http://mitgcm.org/mailman/listinfo/mitgcm-devel
> >>> 
> >>> _______________________________________________
> >>> MITgcm-devel mailing list
> >>> MITgcm-devel at mitgcm.org
> >>> http://mitgcm.org/mailman/listinfo/mitgcm-devel
> >> 
> >> 
> >> _______________________________________________
> >> MITgcm-devel mailing list
> >> MITgcm-devel at mitgcm.org
> >> http://mitgcm.org/mailman/listinfo/mitgcm-devel
> >> 
> > 
> > 
> > _______________________________________________
> > MITgcm-devel mailing list
> > MITgcm-devel at mitgcm.org
> > http://mitgcm.org/mailman/listinfo/mitgcm-devel
> 
> 
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel

More information about the MITgcm-devel mailing list