Up to Specific issues in real coupled models
We would like to include an ice sheet model in our coupled system, however people's thoughts seem to be turning away from using OASIS3-MCT to couple this component to the atmosphere, land, ocean or seaice components. It seems that developers are considering doing the coupling via data files for various reasons. One of the reasons is that the ice-sheet coupling only needs to couple at a frequency of 90 model days. Since our climate models tend to run in chunks of 10 or 30 days before re-submitting this means that in most runs the ice sheet model would not do any coupling and so OASIS3-MCT would have no coupling exchange to perform - which, I think, is not possible at the moment. (Have I got that right? If you have a transient defined in the namcouple then it must do at least one exchange during the run?) So how easy would it be to allow OASIS3-MCT to cater for a model which does not necessarily want to do any coupling during a particular run, and has anyone else dealt with a similar situation in their model configurations? Thanks for any thoughts. Richard
Dear Richard, We discussed about your your problem with Eric today. We need more informations to propose a solution. Do you need to accumulate the ice sheet coupling fields ? Is your coupling frequency (when the ice sheet model is coupling) is always a multiple of the simulation run time ? Is the ice not coupling at all for some runs or does it receive some fields from the atmosphere ? Thanks, Best regards, Laure
Hi Laure and Eric. The ice sheet coupling fields would be instantaneous, or at least they would be values calculated entirely within the ice sheet model, so the coupler would not be expected to do any special meaning or accumulation operations. The coupling frequency could always be made to be an exact multiple of the run time - the coupling is so infrequent (of the order of model weeks/months rather than hours or days) that it probably doesn't really matter if this has to adjusted to satisfy any special conditions which the coupler might impose. In some runs the ice sheet would not be coupling and as you suggest the necessary initial values would just come from the atmosphere (and ocean) restart files, or from some ancillary file. Thanks, Richard
Hello Richard, Laure, the so infrequent coupling you described would exclude OASIS from the solution. Why to implement an interface if a simple reading of initial conditions in ocean and atmosphere restart file is enough ? On the other hand, to include the ice-sheet model would help to clarify the workflow structure, because you wouldn't need to launch separate ice-sheet model stand alone simulation and ensure, with scripts, the synchronization with the ocean-atmosphere simulation. It seems possible to increase the coupling time step to the total simulation length, so that exchanges would only occur at start (and end) of the simulation. You just would have to decide when simulation starts if ice-sheet model has to be launched or not for update. My feeling is that we have to better understand on which ice-sheet grid the OASIS exchange can be done with the other models. At least, I suppose that the ice-sheet model must provide outputs on some grid. Is this grid usable for exchanges with ocean/atmosphere ? Another way to ask the same question would be: if ice-sheet model has to provide/receive information to ocean/atmosphere through files, is the information available on a grid ? The issue you pointed out concerning mask is still a mystery for me (and I remember that I had the same impression when I talk to the Met-Office ice-sheet people a few years ago). I suppose that the ice-sheet model is changing the land-sea limit: then, the OCEAN-ATMOSPHERE coupling is modified by this change and the OASIS coupling between these 2 models has to be done on a changing land-sea mask. If we assume that the ice-sheet limit won't move DURING the ocean-atmosphere simulation, then, yes, you could change your masks.nc file before starting, and let OASIS re-calculate the interpolation weights file. As far as I know: - it is quite vanguardist: I don't know how NCAR is doing that, maybe Tony Craig could help us ? IPSL's paleoclimate models are including moving ice-sheets. OASIS interpolations are probably recomputed in the pre-processing phase of the ocean-atmosphere simulation because they are using the MAPPING interpolation. - it is not very efficient (weight calculations are not too much parallel, even though an OpenMP version is available for the nearest neighbours operation) but feasible. Eric
Hi Eric, Thanks for that.
Well I don't really know what the best option is. Reading from files periodically is fairly straightforward to achieve with our scheduling system. so perhaps (?) that's the simplest solution in technical terms. However it does require:
i) That the coupled atmosphere-ocean-other things part of the run is shut down, the ice sheet model, using much fewer PEs is then run sequentially and shut down before the atmos-ocean-others starts up again. So the system load will be quite irregular - I don't know what that will do for job scheduling on any given system, but I bet it won't help!
ii) A particular approach to managing restart files which would be substantially different form the case when OASIS is used. (Not necessarily more or less difficult, just different - e.g. we may have to impose a condition whereby you always have to run the atmos-ocean stage before the ice sheet stage when performing a start/restart)
On the other hand, load balancing N-component concurrent systems gets more complicated as N increases so it reduces that complexity. I don't really know what the impact on model throughput will be of switching between atmos-ocean and ice sheet... so I suppose performance is my major concern.
Apparently it's all available in grid form which could easily be handled by OASIS3-MCT - except for the fact that the LS masks apparently change. I asked for some details about why the mask needs to change and was told that because ice sheets sit on top of land, but in many cases this can be below sea level. So for example, as they melt, the sea can rush in to fill the space around (and under them, causing them to float!) so you do get shifts in LS masks.
I'm still not entirely sure I believe that because I'd have thought that if the mask was set up properly in the first place Any ice sheets at risk from being replaced by sea water should be defined as (frozen) sea rather than land, so the fact that it melts would make no difference, unless the sea level rises or falls substantially in which case the LS masks for the entire globe for all fields would have to be recalculated... !
Yes, - regenerating weights files during a run would cause all sorts of problems - not just from a performance point of view but also from the point of view of managing those files. i.e. if you have a 500 year climate run, with the ice sheets changing every 3 months, then potentially you may have to retain 2000 different versions of weights files in order to allow people to go back to a particular stage in the run to perform a restart from any given point.
So from that point of view the sequential alternating of control between atmos-ocean and ice sheet does seem rather more attractive.
Thanks, Richard
Hi all, 1) OASIS as is cannot directly handle coupling periods longer than the run duration, e.g. a coupling every 6 months for a simulation split into 1-month runs 2) But you could indeed with scripts schedule your ice-sheet model to run (and therefore be coupled) for the 1st, 7th, 14th, etc. months/runs and in that case use a different namcouple inclluding the ice-sheet model coupling exchanges 3) From what I understood about ice-sheet model, the big problem is that they indeed do melt and change the sea-land mask; I never understood that the are "replaced" by sea water but I do not think that the solution of initially defining them as frozen see would work, but of course, I may be wrong! 4) If the ice-sheet melts during one run, which would cause the sea-land mask to change (for the next run?), OASIS indeed would have to recalculate the weights and addresses at the beginning of the next run. This is not impossible to do, but as you know on-line calculation of weights and addresses is not parallel and not efficient in OASIS. Of course, you could also use other tools that would be scheduled to do this recalculation between two runs in your workflow. 5) And last but least, OASIS cannot handle sea-land mask that changes during the run (but you all know that). So I think I am not bringing anything new in the debate, I just wanted to make sure that these things were clear .. Best regards, Sophie
Hi Sophie,
For 3 => I do think you're right ! This is something which occasionally crops up in various contexts, not just with ice sheets, and we've never yet attempted a solution based on the idea!
For 4 => Yes there might be something in that... however I've always thought it would make life even more difficult if we have a mechanism which modifies weights and addresses on the fly because, for traceability purposes, we would need to be archiving every variation of weights file as the run progresses, so allow people to go back and restart reproducibly from any given point in a climate run.
For 5 => Yes, and our atmosphere LS masks and ancillary fields tend to be derived from the ocean LS mask so I don't know what the effect of changing that would be during the run, but I'd bet it wouldn't be good.
Thanks for all these remarks, that is useful.
Richard