[MITgcm-devel] recent shelfice_remeshing push
Jean-Michel Campin
jmc at mit.edu
Fri Jan 3 17:14:11 EST 2020
Hi Dan,
Following up:
I thought a little bit about this, and seems that this option:
> b) implement something (when pickupStrictlyMatch=F) to enable to start the run
> with a missing field in the pickup (and in this case the initial value from
> SHELFICEmassFile or SHELFICEtopoFile will be used instead).
would be more convienient (and in the line with other pickup reading).
I will try to see what can be done there when the pickup_shelfice.* is missing,
but would rather wait until PR #312 (Adjust surface position) and PR #319
(rework remeshing code) from main MITgcm repos are merged in as well as PR #16
(Clean experiment shelfice remeshing code) from verification_other repos
since they all involve some shelfice (+ pickup) code.
Cheers,
Jean-Michel
On Thu, Dec 26, 2019 at 06:50:27PM -0500, Jean-Michel Campin wrote:
> Hi Dan,
>
> So regarding (1), R_shelfice is accounted for to update Ro_surf
> (which is passed to SHELFICE_INIT_DEPTHS as argument "rSurfC") so
> everything is good. And BTW, the restart for experiment shelfice_2d_remesh
> is tested successfuly every on several compilers/platforms (see the testing
> page, e.g., http://mitgcm.org/testing/results/2019_12/rs_villon-b_20191226_0/summary.txt ).
>
> And regarding "mixed" restart (i.e, when one or more of the 2 switches:
> SHELFICEMassStepping or SHELFICEremeshFrequency > 0. is changed between
> the first segment and the following segment of the run):
> a) if we turned off SHELFICEMassStepping or SHELFICEremeshFrequency=0,
> we should expect the value of ShelficeMass or R_shelfice to be set
> according to: SHELFICEmassFile or SHELFICEtopoFile ;
> I think that doing differently would be confusing and risky.
> b) your comment is more for the other way, i.e when one of these switches is
> turned on.
> Now, in your original remeshing code (from PR #124, until Aug 30, 2019),
> since there was no real run-time switch for remeshing, the pickup written at the end
> of the first segment would have contained both fields ShelficeMass and R_shelfice
> as soon as ALLOW_SHELFICE_REMESHING was defined.
> But currently,
> 1) only the one needed to restart the same type of run (with same switch)
> will be in the pickup.
> 2) the second segment run will stop cleanly with error message pointing to
> the missing field in the pickup file.
>
> I don't like too much writing unnecessary pickup files (with the risk that other
> users may want to add a new switch to turn it off), so we are left with 2 options:
> a) a new pkg/shelfice logical switch (like: SHI_writeFullPickup ) to
> force to write a pickup with both fields.
> b) implement something (when pickupStrictlyMatch=F) to enable to start the run
> with a missing field iin the pickup (and in this case the initial value from
> SHELFICEmassFile or SHELFICEtopoFile will be used instead). But it might be a
> little more tricky than for other pickup files regarding the logic around
> pickupStrictlyMatch since, for pkg/shelfice, the pickup might be missing completely.
>
> Cheers,
> Jean-Michel
>
> On Wed, Dec 25, 2019 at 02:36:10PM +0000, Daniel Goldberg wrote:
> > Hi J-M
> >
> > Thanks for your response. Regarding ro_surf, i will wait for you to look
> > into this. Looking at the new shelfice_init_depths it might be that my
> > concern is addressed, but will wait for your answer.
> >
> > Regarding (2), this does seem clean to me and i appreciate it. To address
> > faulty runtime settings, it seems like a runtime error could be raised if
> > the metadata of the pickup file is not consistent with runtime params, but
> > this could not be found out until the pickup is read (and even then i am
> > unsure how to implement this though i assume it is possible).
> >
> > I will say though, i am currently running simulations where I run the
> > ocean (and shelfice melt) without evolving shelfice_mass -- simply to
> > ensure the ocean (and melt rate) is spun up to a seasonal cycle -- before
> > allowing the shelfice mass (and ice sheet thickness) to evolve, so that the
> > coupled ice sheet-ocean dynamics are not subject to the ocean spinup. (I
> > feel if others use shelfice_remeshing for similar purposes they may want to
> > do the same.) In this case it is in fact very convenient to start from a
> > pickup with mass_stepping enabled, but limiting the shelfice pickup arrays
> > precludes this. As there are only 2 arrays, would it be very inefficient to
> > simply store both in the pickup file whenever shelfice_remeshing or
> > mass_stepping is enabled? (I guess my scenario could also be addressed with
> > addl runtime parameters, but their meaning would become less intuitive.)
> >
> > Many thanks
> > Dan
> >
> > On Wed, Dec 25, 2019 at 5:09 AM Jean-Michel Campin <jmc at mit.edu> wrote:
> >
> > > Hi Dan,
> > >
> > > Thanks for looking at this.
> > >
> > > Regarding (1), I meed to check. Fortunately I still have a clone
> > > with branch_remeshing there, so should be able to figure out.
> > >
> > > And reagrding (2), I made little changes in our PR #124 but kept
> > > the main things there:
> > > a) S/R SHELFICE_READ_PICKUP is called in 2 places,
> > > 1) the fisrt time in shelfice_init_depths.F, only when using remeshing,
> > > to read in: R_shelfice
> > > 2) the second time in shelfice_init_varia.F , only when
> > > SHELFICEMassStepping=T.
> > > to read in: shelficeMass
> > > b) the only difference is that the fields are only read-in once,
> > > at the right time, instead of twice (each time the S/R was called).
> > > I think this is cleaner, and easier to follow.
> > > c) the current logic make sense to me:
> > > if SHELFICEMassStepping=F, we don't need to read again shelficeMass
> > > because
> > > it has not been updated ;
> > > if no remeshing, initial R_shelfice is kept to it's initial value,
> > > so no need to read it from pickup.
> > > d) there are some more complicated cases when one decide to turn on or off
> > > SHELFICEMassStepping and/or remeshing and try to restart from a
> > > previous
> > > pickup. This is tricky, and I did not try anything that would increase
> > > the chances to make this kind of mixed restart successful - but nothing
> > > specific to these cases was there in your PR #124 neither.
> > >
> > > Will have an update regrading (1) soon ; if not, please remind me.
> > >
> > > Cheers,
> > > Jean-Michel
> > >
> > >
> > > On Tue, Dec 24, 2019 at 03:33:37PM +0000, Daniel Goldberg wrote:
> > > > Hi Jean Michel
> > > >
> > > > I have been looking through the recent commit for the shelfice_remeshing
> > > > P/R, and have a few questions, both regarding shelfice_init_varia.
> > > >
> > > > 1) I believe that in my P/R i had code under "IF (shelficeMassStepping)"
> > > to
> > > > reinitialise ro_surf to r_shelfice if a pickup is loaded. This is because
> > > > INIT_DEPTHS() is only called in INITIALISE_FIXED(), and so otherwise
> > > > ro_surf will not be updated, I don't think. Do you agree, and if so, was
> > > > this addressed elsewhere in your commit?
> > > >
> > > > (also -- apologies if this code was not in my P/R. I had created a new
> > > > branch for horizontal remeshing off of the remeshing branch; and now
> > > that i
> > > > have removed my remeshing branch I am not sure if this change was
> > > > reflected.)
> > > >
> > > > 2) Current logic is to read from a pickup only if shelficeMassStepping is
> > > > turned on. But remeshing can occur even when Ice shelf mass does not
> > > > change, e.g. if initial hFac's are set as to trigger remeshing
> > > thresholds.
> > > > (One could argue that care should be taken in initialisation, but in
> > > > practice such situations could be difficult to avoid due to free surface
> > > > changes.) Would it be possible to read from the shelfice pickup whenever
> > > > remeshing is allowed?
> > > >
> > > > Many thanks
> > > > Dan
> > >
> > > > _______________________________________________
> > > > 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