[MITgcm-devel] issues with xx_gentim2d

Martin Losch Martin.Losch at awi.de
Thu Oct 1 15:43:39 EDT 2020 

Hi Gael and others,

I now think, I know what’s happening with these meta files. S/R mds_write_field has an argument iRec that is passed to S/R mds_write_meta which then writes the value if iRec as nrecords into the meta file. In a forward integration this is useful (and probably intended), as each time a new record is written a new meta file contains the value of the latest records. 
In the backward integration the adxx_files (initialized to zeros) are overwritten, record by record, and the ever decreasing value of iRec is stored in the meta file (overwriting the previous one) until we are at iRec=1 and the intergration is over. The solution to this is not to write any meta file in the backwards integration. It’s not necessary, because the meta file of the initialization is OK. One can do this by passing “-iRec” to any “MDS_WRITE*” in active_file_control.F, see <https://github.com/mjlosch/MITgcm/blob/ctrl_gentim2d_fix/pkg/autodiff/active_file_control.F>

This is totally independent of and unrelated to the xx_gentim2d issue.

I have created an issue for the xx_gentim2d problem, and I have a solution that I will submit as a PR if no-one objects. (you can always object later, I guess), but I’d appreciate if you could check if my solution is plausible and complete, especially Gael, because it’s your code, and you may have had good reasons for doing it as it is.

Martin


> On 1. Oct 2020, at 20:08, Gael Forget <gforget at mit.edu> wrote:
> 
> I am not sure
> 
>> On Sep 30, 2020, at 10:16 AM, Martin Losch <Martin.Losch at awi.de> wrote:
>> 
>> Hi Gael,
>> 
>> do you agree that this is a bug? My fix solve the problem of the model stopping in the initialization phase, but it introduces a different error where the parameter nrecords in adxx_*.meta is set to a number that is different from the actual records. This is mostly a problem for reading with rdmds or similar, but I suspect that it may also mean that the records are screwed up now.
>> 
>> Martin
>> 
>>> On 30. Sep 2020, at 15:36, MIT <gforget at mit.edu> wrote:
>>> 
>>> Please consider posting this as an issue to mitgcm repo (if not already done)
>>> 
>>> Gael
>>> 
>>> Sent from my iPhone
>>> 
>>>> On Sep 30, 2020, at 8:30 AM, Martin Losch <Martin.Losch at awi.de> wrote:
>>>> 
>>>> Hi An (and others),
>>>> 
>>>> thanks for pointing me to that PR. Unfortunately, my issue is different. What TIm described is a convenience setting when running a shorter intergration period in the middle of the ECCO period. In my set up, the model doesn’t even reach the first time forward timestep. I think these two are unrelated.
>>>> 
>>>> I was actually wrong about my setup: I don’t use the ecco pkg and I don’t compile it either in this setup.
>>>> 
>>>> Basically I cannot start an adjoint simulation from an arbitrary pickup. I can quick-and-dirty-fix this issue by simply renaming the pickups to nIter0=1 or so (as has been done for the ECCOv4 setup), but I don’t think that this was intended.
>>>> 
>>>> My fix to this can be found here:
>>>> 
>>>> https://github.com/mjlosch/MITgcm/tree/ctrl_gentim2d_fix/pkg/ctrl
>>>> 
>>>> Any thoughts? Maybe you can test, whether this branch ctrl_gentim2d_fix affects your simulations, or not. It does not affect the ad-verification experiments and nor verification_other/global_oce_cs32, so I am inclined to create a PR ...
>>>> 
>>>> Martin
>>>> 
>>>>> On 30. Sep 2020, at 00:21, An Nguyen <antnguyen13 at gmail.com> wrote:
>>>>> 
>>>>> hi Martin,
>>>>> 
>>>>> Tim (Smith) has put in a pull-request to fix this problem last year (I believe it's the same issue you're encountering), see: https://github.com/MITgcm/MITgcm/pull/260
>>>>> 
>>>>> cheers,
>>>>> An
>>>>> 
>>>>>>> On Sep 29, 2020, at 11:28, Martin Losch <Martin.Losch at awi.de> wrote:
>>>>>> 
>>>>>> Hi all,
>>>>>> 
>>>>>> I am having trouble with using the generic control variables. I am pretty sure this has been discussed somewhere already, but I cannot find it. I use the ecco package.
>>>>>> 
>>>>>> Here’s the problem:
>>>>>> data.cal: 
>>>>>> startDate_1=19470101,
>>>>>> 
>>>>>> data:
>>>>>> &PARM03
>>>>>> # 2000,1,1
>>>>>> nIter0=464592,
>>>>>> nTimeSteps=1600,
>>>>>> deltaT    = 3600.,
>>>>>> 
>>>>>> That is, I am starting from a pickup and I get about 66.66 days of integration. In data.ctrl I have this:
>>>>>> 
>>>>>> xx_gentim2d_file(1)='xx_precip',
>>>>>> xx_gentim2d_startdate1(1)=19991231,
>>>>>> xx_gentim2d_startdate2(1)=180000,
>>>>>> xx_gentim2d_period(1)=1209600.0,
>>>>>> (but I also tried 20000101, 000000 and 6hr into the new year etc.)
>>>>>> 
>>>>>> So the period is 14 days. My integration time is less than 5 times than that. I would expect that I get 5 records of xx_precip. In ctrl_init, 7 records are written to xx_precip.000000000.data, but in ctrl_map_ini_gentim2d the program stops while attemping "to access non-existing record in xx_precip.0000000000.data". A closer inspection reveals, that this happens when we try to read record 8 (which was never written), in fact, the loop in which this happens would go to record 2772, which is the value of endrec, the value of startrec being 2766 and diffrec is the expected 7.
>>>>>> 
>>>>>> When I replace endrec by diffrec in quite a few places, the simulation runs (but I have no idea if it does the right thing ... for me it probably does, because there are only zeros in xx_precip.000000000.data and it doesn’t matter if I add the wrong set of zeros.)
>>>>>> 
>>>>>> So I think that this is a bug, because the code of ctrl_map_ini_gentim2d.F assumes a startrec of 1 and totally does not work when nIter0 >> 1 (the ECCOv4 setup starts from a pickup with nIter0=1, not sure if this is a remedy that’s supposed to be universal, or it just happened to be convenient).
>>>>>> 
>>>>>> If you agree that this is a bug, I can start an issue on github. If you think it’s a user error, then please point me in the right direction, to the documenation, or some support/devel info that can help me use this piece of code correctly. Any pointer is welcome.
>>>>>> 
>>>>>> Martin
>>>>>> _______________________________________________
>>>>>> MITgcm-devel mailing list
>>>>>> MITgcm-devel at mitgcm.org
>>>>>> http://mailman.mitgcm.org/mailman/listinfo/mitgcm-devel
>>>>> 
>>>>> _______________________________________________
>>>>> MITgcm-devel mailing list
>>>>> MITgcm-devel at mitgcm.org
>>>>> http://mailman.mitgcm.org/mailman/listinfo/mitgcm-devel
>>>> 
>>>> _______________________________________________
>>>> MITgcm-devel mailing list
>>>> MITgcm-devel at mitgcm.org
>>>> http://mailman.mitgcm.org/mailman/listinfo/mitgcm-devel
>>> 
>>> _______________________________________________
>>> MITgcm-devel mailing list
>>> MITgcm-devel at mitgcm.org
>>> http://mailman.mitgcm.org/mailman/listinfo/mitgcm-devel
>> 
>> _______________________________________________
>> MITgcm-devel mailing list
>> MITgcm-devel at mitgcm.org
>> http://mailman.mitgcm.org/mailman/listinfo/mitgcm-devel
> 
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mailman.mitgcm.org/mailman/listinfo/mitgcm-devel

More information about the MITgcm-devel mailing list