The OASIS Coupler Forum

  HOME

Number of grid points in namcouple record

Up to Specific issues in real coupled models

Posted by Anonymous at January 20 2021

Hi,

Currently, in order to get the fields produced by EXPOUT in the right format for simple analysis, plotting, etc, we need to provide the source and target field dimensions in the namcouple record, e.g. the first four numbers in the following line:

182 149 128 64 toce atmo LAG=+14400 SEQ=+1

I _think_ I recall a conversation a while ago about the intention to remove the need to supply these. That would obviously be helpful in the sense that it means we could reuse the same namcouple file for models using different resolutions, or when generating namcouple files we have fewer things to capture to include in the namcouple file. Have I mis-remembered that conversation, or is it something which is may potentially happen at some stage?

Thanks, Richard

Posted by Anonymous at January 25 2021

Hi Richard,

Honestly, we (oasis developers) don't remember anything about this. If we get rid of the 2D information in the namcouple, we could add a new optional argument to the partition to define the 2d sizes in the def_partition interface. It should not be very difficult to do.

Let us know how urgent/useful this is.

Posted by Anonymous at January 26 2021

Thanks for the reply.

I must have dreamed (or wished) it or misheard! It's just something that came up recently here as we're planning how to create namcouple's dynamically at run time so we need to capture the essential information from component models for a lot of what goes into the namcouple. I thought if OASIS3-MCT was likely to take care of that then it would be something we wouldn't have to worry about. The optional argument for the partitions sounds like something we'd be interested in because it reduces the amount of data which needs to be known BEFORE each component starts up. It shouldn't be a huge deal for us to manage, at least for components like the UM, NEMO and LFRic, so I wouldn't say it's urgent, but it does mean we currently have to interrogate things like component namelists and environment variables, so it would make things easier if something like that were available.

Thanks, Richard
Reply to this