[MITgcm-devel] missing barrier causing problems for packing

[Matthew Mazloff]

Hi Jean-Michel

Yes, an MPI_BARRIER call, thanks for clarifying.

And at the top of CTRL_PACK would be a great place for it.  Would it  
be ok for me to check this in -- does anyone have any objections?

An alternative fix would be to pack the ctrls first, then the  
gradients.....

let me know, thanks
-Matt





On Jan 30, 2012, at 4:05 PM, Jean-Michel Campin wrote:

> Hi Matt,
>
> Just to clarify a detail: you mean an MPI_BARRIER call
> (the usual _BARRIER just sync threads and does not do anything
> between different MPI procs).
>
> There is an example of such a call in ini_procs.F
> (the one in eeboot_minimal.F is not the right one)
>
> And as where to put it, may be (naively) at the top of S/R CTRL_PACK ?
>
> Cheers,
> Jean-Michel
>
> On Mon, Jan 30, 2012 at 02:13:19PM -0800, Matthew Mazloff wrote:
>> Hello
>>
>> We have come across the problem where the packing initiates before
>> all processors finish writing adxx_theta, and thus sometimes
>> ecco_cost is incorrect (zeros were read/written instead of proper
>> gradients.)
>>
>> We need to have a barrier put in either
>>
>> around line 261 at the beginning of the_main_loop.F before
>> CALL INITIALISE_VARIA( mythid )
>>
>> or in the_model_main.F  around line 600 between
>>      CALL THE_MAIN_LOOP( myCurrentTime, myCurrentIter, myThid )
>> and
>>         CALL CTRL_PACK( .FALSE. , mythid )
>>
>>
>> Let me know what is preferable -- and if someone wants to go ahead
>> and check this in that would be great!
>>
>> Thanks
>> Matt
>>
>>
>>
>> _______________________________________________
>> 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