[MITgcm-devel] seaice dynamics questions
Jean-Michel Campin
jmc at ocean.mit.edu
Thu Sep 22 19:17:17 EDT 2011
Hi Michael & Dimitris,
Thanks for the information. This helps.
Don't know yet how/when I will try something,
but I will keep these options unchanged.
Cheers,
Jean-Michel
On Thu, Sep 22, 2011 at 03:48:03PM -0700, Michael Schodlok wrote:
>
> those are my OBCS seaice options
>
> I apparently did not turn the avoid convergence on for the 1 km grid
> but it still works and I did not have any issues with it.
> As discussed a while ago for this resolution something like
> avoid_divergence,
> or rbcs would be good.
>
> #undef OBCS_SEAICE_AVOID_CONVERGENCE
> #undef OBCS_SEAICE_SMOOTH_UVICE_PERP
> #undef OBCS_SEAICE_SMOOTH_UVICE_PAR
> #undef OBCS_SEAICE_SMOOTH_EDGE
> #define OBCS_SEAICE_COMPUTE_UVICE
>
> Michael
>
>
> >Michael, what SEAICE_OBCS options
> >do you use for your 1-km integrations?
> >
> >Jean-Michel, at a minimum I think that
> >OBCS_SEAICE_AVOID_CONVERGENCE
> >needs to be supported.
> >
> >Thanks
> >
> >Dimitris Menemenlis
> >
> >On Sep 22, 2011, at 4:07 PM, Jean-Michel Campin wrote:
> >
> >>Hi,
> >>
> >>I made some changes in seaice_lsr.F that should fix the point 2
> >>below. I've checked that it does not break completly the adjoint
> >>(I got roughtly the same number of recomputation warnings, and
> >>it's not slower to run) but it might be worth to check.
> >>
> >>Regrding point 3 (obcs + seaice velocity): I would like to know
> >>which CPP options in obcs_apply_uvice.F are currently used
> >>(in order to know which one to keep unchanged if I made some
> >>modifications):
> >>OBCS_SEAICE_COMPUTE_UVICE
> >>OBCS_SEAICE_SMOOTH_UVICE_PAR
> >>OBCS_SEAICE_SMOOTH_UVICE_PERP
> >>OBCS_SEAICE_AVOID_CONVERGENCE
> >>The idea is that I could try to implement some masking in
> >>seaice_lsr.F, and calling obcs_apply_uvice before seaice_lsr
> >>(or at the top of it); but I need to know what to do with what is
> >>currently in obcs_apply_uvice.F
> >>
> >>Cheers,
> >>Jean-Michel
> >>
> >>On Thu, Sep 01, 2011 at 02:18:59PM -0400, Jean-Michel Campin wrote:
> >>>Hi,
> >>>
> >>>I have a couple of questions and remarks regarding pkg/seaice:
> >>>
> >>>1) I found annoying not to be able to know where some CPP options
> >>>should be defined/undef, since they don't appears in any
> >>>*OPTIONS.h files, neither set at the top of the *.F file
> >>>in which they are used (might want to use this to keep some
> >>>inactive pieces of code):
> >>>DISABLE_SEAICE_OBCS <- I guess in SEAICE_OPTIONS.h ?
> >>>and many more in other seaice S/R.
> >>>
> >>>2) LSR solver: we always do uIce first and then vIce, right ?
> >>>and I guess the vIce solution depend on the new uIce.
> >>>Now when the seaice extends over 2 faces of the CS-grid,
> >>>might have an issue with U/V not being continuous at the
> >>>face boundary. As I understand, it's not so much an issue on
> >>>regular CS grid (e.g., CS-510) for present day conditions but
> >>>this is likely to happen on lat-lon cap grid. I guess the
> >>>solution would be to have a 3 pass algorithm, like in
> >>>multi-dim advection with CS topology.
> >>>
> >>>3) I did not find many OBCS specific code in seaice_lsr.F
> >>>Would it make sense to prevent the LSR solver from updating
> >>>the ice velocity at the OB (like we do in CG2D) ?
> >>>Would it be useful ? Might not be too difficult with some masking.
> >>>
> >>>4) I am going to add an EXCH call at the end of obcs_apply_uvice.F,
> >>>since it seems we need one. I am also tempted to remove
> >>>all the "if ( OB?u/vicefile .NE. ' ' ) then" : I think it's
> >>>not right and not safe to by-pass the setting of ice-velocity at
> >>>an open-boundary, and it's better to apply a default zero velocity
> >>>when no file is provided.
> >>>
> >>>Cheers,
> >>>Jean-Michel
> >
> >
>
>
> --
> --
> --
>
> *************************************************
>
> Michael Schodlok <schodlok at jpl.nasa.gov>
> Jet Propulsion Lab/
> California Institute of Technology
> MS 300-323
> 4800 Oak Grove Dr
> Pasadena CA 91109-8099 USA
> Tel: +1-818-354-4015 Fax: +1-818-393-6720
>
> *************************************************
>
>
>
More information about the MITgcm-devel
mailing list