[MITgcm-devel] GLOBAL_SUM in cost_final.F

[Martin Losch]

Hi Jean-Michel,

my 5 cents worth: I agree that your version (3) is the best, but I only have very set ups so any change would be simple to accomodate, so my opinion may not weigh as much as others.

Martin

On Oct 24, 2013, at 8:59 PM, Jean-Michel Campin <jmc at ocean.mit.edu> wrote:

> Hi,
> 
> I started to test some changes in pkg/cost/cost_final.F,
> to replace the call to           GLOBAL_SUM_RL( fc , myThid ) 
> with a call to    GLOBAL_SUM_TILE_RL( tile_fc , fc , myThid )
> 
> There is a practical advantage to do this is that I can get
> better forward gradient agreement when using MPI compared to non-MPI
> (when GLOBAL_SUM_SEND_RECV is defined in CPP_EEOPTIONS.h). 
> For instance, with tutorial_tracer_adjsens, forward grad 
> testreport with MPI will give 16 digits for forward grad 
> whereas now it's only 5 (on baudelaire with gfortran).
> 
> There is also a less obvious advantage is that 
> GLOBAL_SUM_RL( fc , myThid )
> gives the wrong results when using multi-threads (since
> fc is in common block).
> 
> I have several versions that I can check-in:
> 1) only changes in cost_final.F (but this leave on the side
> few other cost contributions.
> 2) add "tile_fc(bi,bj)" to cost.h and change
> cost_final.F seaice_cost_final.F shelfice_cost_final.F thsice_cost_final.F
>  (the only pkg that would need GLOBAL_SUM_RL( fc ) would be pkg/ecco)
> 3) same as (2) + also change ecco_cost_final.F
>  (changes are not major, total of 6 lines, changing
>   fc = fc
>  to
>   tile_fc(bi,bj) = tile_fc(bi,bj)
>  )
> I think (3) would be cleaner (and easier to follow and check), but I don't
> know how many different versions of ecco_cost_final.F users have.
> 
> Suggestions ?
> 
> Cheers,
> Jean-Michel
> 
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel