[MITgcm-devel] testreport again

Wed Apr 8 03:02:05 EDT 2015

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