Reading and writing of coupling fields

[aidanheerdegen]

I am trying to get a handle on where the various OASIS coupling fields are read from and written to at the beginning and end of each model invocation.

This is what I believe to be the current state, can anyone confirm I have this right?

a2i.nc

written out to work/atmosphere/INPUT from cpl_interfaces.F90

https://github.com/OceansAus/matm/blob/2c6add9fd24580eba08d6791e1bcdf77793889d2/source/cpl_interfaces.F90#L426

Read in through oasis/namcouple, I think in this routine somewhere:

https://github.com/OceansAus/oasis3-mct/blob/6cceb38c4c4b3d11ea0d9c5bacd7442320d69538/lib/psmile/src/mod_oasis_advance.F90#L26

o2i.nc

written out to work/ocean/ from mom_oasis3_interface.F90

https://github.com/mom-ocean/MOM5/blob/5dd8e902f7a0f7ac043730c3641301fdd3da4232/src/access_coupler/mom_oasis3_interface.F90#L784

read in from input_dir from CICE_RunMod.F90

https://github.com/OceansAus/cice5/blob/5583ce54fd8822c1b8aef0549090167ca5f36d10/drivers/auscom/CICE_RunMod.F90#L106

i2o.nc

read in from input_dir from CICE_RunMod.F90

https://github.com/OceansAus/cice5/blob/5583ce54fd8822c1b8aef0549090167ca5f36d10/drivers/auscom/CICE_RunMod.F90#L108

Written to restart_dir from CICE_RunMod.F90

https://github.com/OceansAus/cice5/blob/5583ce54fd8822c1b8aef0549090167ca5f36d10/drivers/auscom/CICE_RunMod.F90#L228

ping @nicjhan @marshallward @russfiedler

[aidanheerdegen]

I am trying to understand if something like this is a problem:

$ pwd
/g/data3/hh5/tmp/cosima/access-om2-025/025deg_jra55v13_ryf8485_redi3
$ md5sum restart*/coupler/a2i.nc
a45788fb3f3aa1fd3f5678bc97f1c846  restart000/coupler/a2i.nc
a45788fb3f3aa1fd3f5678bc97f1c846  restart005/coupler/a2i.nc
a45788fb3f3aa1fd3f5678bc97f1c846  restart010/coupler/a2i.nc
a45788fb3f3aa1fd3f5678bc97f1c846  restart015/coupler/a2i.nc
a45788fb3f3aa1fd3f5678bc97f1c846  restart020/coupler/a2i.nc
a45788fb3f3aa1fd3f5678bc97f1c846  restart025/coupler/a2i.nc
a45788fb3f3aa1fd3f5678bc97f1c846  restart030/coupler/a2i.nc
a45788fb3f3aa1fd3f5678bc97f1c846  restart035/coupler/a2i.nc
a45788fb3f3aa1fd3f5678bc97f1c846  restart040/coupler/a2i.nc
a45788fb3f3aa1fd3f5678bc97f1c846  restart045/coupler/a2i.nc
a45788fb3f3aa1fd3f5678bc97f1c846  restart050/coupler/a2i.nc
a45788fb3f3aa1fd3f5678bc97f1c846  restart055/coupler/a2i.nc
a45788fb3f3aa1fd3f5678bc97f1c846  restart060/coupler/a2i.nc
a45788fb3f3aa1fd3f5678bc97f1c846  restart065/coupler/a2i.nc
a45788fb3f3aa1fd3f5678bc97f1c846  restart070/coupler/a2i.nc

[russfiedler]

@aidanheerdegen I don't think that a2i.nc is used since the coupling of the atmosphere to the ice is aligned in time.

[aidanheerdegen]

Thanks @russfiedler.

The namcouple file has entries like this:

##########
# Field 01 : swflx down
##########
swfld_ai swfld_i 367 10800 3 a2i.nc EXPORTED
jrat cict LAG=+1800 SEQ=+1
P  0  P  0
#
LOCTRANS MAPPING SCRIPR
INSTANT
rmp_jrat_to_cict_CONSERV.nc dst
CONSERV LR SCALAR LATLON 10 FRACNNEI FIRST

If the LAG value is the same as timestep then they are aligned in time?

It is kept there in case there is a forcing that isn't aligned in time I guess? Does that ever happen for a MATM model?

I wonder if there is a loss of generality if unused coupling files simply weren't included to avoid complexity and confusion.

[nichannah]

Hi @aidanheerdegen, good on you for looking into this. I agree that it's not clear what is going on here.

Do you know which version of payu is being used here? My test run doesn't show this same behaviour - the checksums of a2i.nc in restart/coupler are changing.

P.S. as a side thought, have we considered packaging particular versions of payu with the model itself?

[aidanheerdegen]

Hey @nicjhan. The example above was run by @AndyHoggANU. I don't know what version of payu he used, I assumed payu/0.8.

As @russfiedler says it doesn't make any difference in this case, but I agree that it is important as it may be a hidden bug for a case where the data in that file is utilised.

I think we have talked about packaging payu, but I can't recall specifics. It might have been discussed as part of your idea of packaging an entire run, containerised.

One issue is payu is currently quite raijin-centric. That would need to be addressed first IMO.

[ofa001]

I haven't looked at the coupler code for the standalone ice_ocean-matm set up for a while willing to do so, but @russfiedler is probably write in saying a2i may not be in use, its definitely part of our coupled model exchange code. Will get back to you in a short while

[ofa001]

A2i calls have been commented out in our auscom drivers (CICE_RunMod.F90 for a number of years and that what you picked up.

I am not sure though wether the one that Dave Arnold and Hailin worked on last year (Sept) was ever passed on to you, with some bug fixes, I think that might have been happening when Peter D and Nic aligned codes or it might have happened through the technical group that I am not on.

[russfiedler]

If you're worried about the reading of the restart file or otherwise you can check the info argument in the call to prism_get_proto. It shouldn't be equal OASIS_From_Restart(=10) See section 2.2.7 of the Oasis manual.. Restart files (if needed) should be created automatically (Sec 5.2). I'm not quite sure why we even write them out explicitly unless the number of coupling steps is inconsistent with what the library thinks it should be and therefore doesn't write the coupling fields automatically.

[marshallward]

Nothing to add to the OASIS restart discussion, just wanted to say to @ofa001 that you are always welcome to attend the technical working group meetings. There is no formal roster or membership, it's for anyone interested in software or data issues around COSIMA modelling.

As for bundling payu with OM2: I'm not against it, but we are usually on top of these problems and I would expect that we'd always use the latest version of payu, and that it would work correctly. We're probably not being as strict about this at the moment since OM2 is moving so fast, but I would hope that would not change in the future.

[nichannah]

I’m revisiting this as part of some matm improvements. it looks to me like it is needed/used because the namcouple uses lag=+3600 and the first cice atmosphere read is at time=0.

I'd like to make sure that @aekiss 0.1 runs are doing this properly because they have sub-year restarts.

If a run is using RYF and has yearly or multi-yearly resubmits the a2i.nc will always look the same because it is always a snapshot of the last forcing of the year.