[MITgcm-devel] changes in seaice with OBCS
Jean-Michel Campin
jmc at ocean.mit.edu
Thu Nov 11 22:09:17 EST 2010
Hi Dimitris and Martin,
Thanks for the answer.
I think I am going to remove all the:
> IF ( SEAICEadvHeff .AND. OBNhfile .NE. ' ' )
in obcs_apply_seaice.F, so that it will do what the other obcs_apply
do, i.e., set the value at the OB.
I am not sure it's going to slow down or speed up:
If the computation follows exactly the fortran code,
it will save many tests on file name
( (sNx x Oly +sNy x Olx ) x 2 x Number_of_iceFlds )
(which are slower that test on real or integer),
so it could speed-up this routine.
If the compiler re-arrange the loop, then I don't know,
and it could become slower (need to access variable in common
blocks to do the copy, whereas could by-pass this in the
present version).
But in any case, there is not much computation in thoses obcs_apply S/R,
just copy from array to array.
Regarding obcs_apply_uvice.F, I am not going to change things now,
but I think it would be safer also to remove those tests on non empty
OB-file name:
In the case where OB far from the seaice pack (e.g., at the equator)
influence the ice dynamics in the arctic, then it's probably better
to set the ice-velocity to zero at the equator (the default if no
file is provided). And if the influence is significant and cannot
be ignored, it means it's necessary to provide non-zero OB value
(read in from a file) for ice velocity.
Martin, do you have an opinion on this ? (I read the exchange of emails
from Feb. 2009, but I don't see how the domain could have an OB
for the ocean but not for seaice, unless it's only at depth ?)
Cheers,
Jean-Michel
On Thu, Nov 11, 2010 at 10:52:57AM -0800, Menemenlis, Dimitris (3248) wrote:
> JM, sorry for delay in getting back.
> I was on way back from a meeting in Seattle yesterday.
>
> The reason for existence of
> > IF ( SEAICEadvHeff .AND. OBNhfile .NE. ' ' )
> etc., in obcs_apply_seaice.F and
> > if ( OBEuicefile .NE. ' ' ) then
> etc., in obcs_apply_uvice.F is the following.
> There are model configurations when the open boundary
> is in a location that never sees sea ice
> and yet the model uses pkg/seaice
> because ice can form away from the boundaries.
> Examples of such configurations are the
> pan-Arctic set-ups that, e.g., Patrick, An, Manfredi, Gunnar,
> and Pierre are using. In the pan-Arctic case all the boundaries
> are permanently in ice-free water but there can be
> configurations where only some of the open boundaries
> would be in open water.
>
> Regarding obcs_apply_seaice.F
> we can get rid of conditions:
> > IF ( SEAICEadvHeff .AND. OBNhfile .NE. ' ' )
> etc., and it should not affect numerical results.
> This is because all the ice tracer quantities are
> initialized to zero in any case. It would only mean
> a few extra computations and subroutine calls,
> which do nothing, but I don't think the code slow
> down would be noticeable.
>
> Regarding obcs_apply_uvice.F
> I also think we can also get rid of
> > if ( OBEuicefile .NE. ' ' ) then
> etc., but I am not 100% sure if it will have
> numerical consequences. This is
> because in LSR case, ice velocity is non-zero
> even when there is no sea ice.
>
> Dimitris
>
> Dimitris Menemenlis <menemenlis at jpl.nasa.gov>
> Jet Propulsion Laboratory, California Institute of Technology
> MS 300-323, 4800 Oak Grove Dr, Pasadena CA 91109-8099, USA
> tel: 818-354-1656; cell: 818-625-6498; fax: 818-393-6720
>
> On Nov 11, 2010, at 12:17 AM, Martin Losch wrote:
>
> > Hi Jean-Michel,
> >
> > yes, that was the point: with OBCS_SEAICE_COMPUTE_UVICE defined there should not be any files for open boundaries for ice velocities. I had suggested something about these tests some time ago <http://mitgcm.org/pipermail/mitgcm-devel/2009-February/003602.html>, but I didn't follow up on that.
> >
> > Martin
> >
> > On Nov 10, 2010, at 8:07 PM, Jean-Michel Campin wrote:
> >
> >> Hi Martin,
> >>
> >> I did not think of changing obcs_apply_uvice.F now (just obcs_apply_seaice.F).
> >> But, naively, looks like removing the test for non empty OBN,Svicefile and
> >> OBE,Wuicefile in obcs_apply_uvice.F would make your data.obcs more
> >> staighforward (no need to specify OBW,Eu,viceFile when OBCS_SEAICE_COMPUTE_UVICE
> >> is defined).
> >> Or am I missing something ?
> >>
> >> Cheers,
> >> Jean-Michel
> >>
> >> On Wed, Nov 10, 2010 at 03:38:47PM +0100, Martin Losch wrote:
> >>> Hi Jean-Michel,
> >>>
> >>> I actually use some of this in an awkward way. What I want is that all ice that reaches the boundary, disappears. Not sure if it really works, but the ice does not pile up against the boundary, so I am happy. Here an excerpt from my data.obcs. aaomip_heff.obce contains only zeros.
> >>>> # all zeros
> >>>> OBEhFile='../input/aaomip_heff.obce'
> >>>> OBWhFile='../input/aaomip_heff.obce'
> >>>> OBEaFile='../input/aaomip_heff.obce'
> >>>> OBWaFile='../input/aaomip_heff.obce'
> >>>> OBEsnFile='../input/aaomip_heff.obce'
> >>>> OBWsnFile='../input/aaomip_heff.obce'
> >>>> # this is very counterintuitive: we need to specify
> >>>> # an input field for the code to do anything, even
> >>>> # though with the current CPP Flag settings
> >>>> # (OBCS_SEAICE_COMPUTE_UVICE defined), these values
> >>>> # have no effect whatsoever
> >>>> OBWuiceFile='../input/aaomip_heff.obce'
> >>>> OBWviceFile='../input/aaomip_heff.obce'
> >>>> OBEuiceFile='../input/aaomip_heff.obce'
> >>>> OBEviceFile='../input/aaomip_heff.obce'
> >>>
> >>> I agree with you that this is not very practice, and something more straightforward would be nice (like defining or computing the values in obcs_calc.F).
> >>>
> >>> Martin
> >>>
> >>> On Nov 10, 2010, at 3:30 PM, Jean-Michel Campin wrote:
> >>>
> >>>> Hi Dimitris,
> >>>>
> >>>> Thanks for doing this. I made the checkpoint62n tag yesterday.
> >>>>
> >>>> I have an other question related to obcs_apply_seaice.F:
> >>>> I would like to remove all the conditions on non-empty
> >>>> file-name when applying OBC to seaice fieds:
> >>>>> IF ( SEAICEadvHeff .AND. OBNhfile .NE. ' ' )
> >>>>> & HEFF(I,J,bi,bj) = OBNh (I,bi,bj)
> >>>>> IF ( SEAICEadvArea .AND. OBNafile .NE. ' ' )
> >>>>> & AREA(I,J,bi,bj) = OBNa (I,bi,bj)
> >>>> In fact, I don't know how the seaice model will deal with OB
> >>>> when only part of the fields are specified in OB regions.
> >>>> I expect some funny things when the ice-field is advected.
> >>>> And in the case where the ice field is not advected, I really
> >>>> don't know. I would be tempted to remove also the test
> >>>> "IF ( SEAICEadvHeff )", and to always apply what has been
> >>>> set in obcs_calc, to make seaice-obcs like ptracer,T,S,
> >>>> and momentum (all the other obcs_apply S/R).
> >>>>
> >>>> But may be a more basic question, is this feature (not to
> >>>> apply OBC to some seaice-fields when it's done for other
> >>>> fields) used and for what purpose ?
> >>>> If this is really a feature we want to maintain, I am afraid
> >>>> this might be broken after my recent changes.
> >>>>
> >>>> Cheers,
> >>>> Jean-Michel
> >>>>
> >>>> On Mon, Nov 08, 2010 at 01:37:52PM -0800, Menemenlis, Dimitris (3248) wrote:
> >>>>> JM, I will revert back to 1.50 plus your 1.52 changes.
> >>>>> will check it in in a few minutes, after I test make sure I didn't
> >>>>> break seaice_obcs
> >>>>>
> >>>>> D.
> >>>>>
> >>>>>
> >>>>> On Nov 8, 2010, at 1:07 PM, Jean-Michel Campin wrote:
> >>>>>
> >>>>>> Hi Dimitris,
> >>>>>>
> >>>>>> I made some changes in OBCS for T & S, also ptracers,
> >>>>>> and did similar changes in pkg/seaice.
> >>>>>> If you see something strange, let me know.
> >>>>>>
> >>>>>> I was going to make a checkpoint sometime this week
> >>>>>> (may be tomorrow), and was wondering about your changes in
> >>>>>> seaice mask with OBCS (in seaice_init_varia): Do prefer to change
> >>>>>> it back ? Anyway, it would be better to fix it
> >>>>>> before the checkpoint (62n).
> >>>>>>
> >>>>>> Cheers,
> >>>>>> Jean-Michel
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> MITgcm-devel mailing list
> >>>>>> MITgcm-devel at mitgcm.org
> >>>>>> http://mitgcm.org/mailman/listinfo/mitgcm-devel
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> MITgcm-devel mailing list
> >>>>> MITgcm-devel at mitgcm.org
> >>>>> http://mitgcm.org/mailman/listinfo/mitgcm-devel
> >>>>
> >>>> _______________________________________________
> >>>> MITgcm-devel mailing list
> >>>> MITgcm-devel at mitgcm.org
> >>>> http://mitgcm.org/mailman/listinfo/mitgcm-devel
> >>>
> >>>
> >>> _______________________________________________
> >>> MITgcm-devel mailing list
> >>> MITgcm-devel at mitgcm.org
> >>> http://mitgcm.org/mailman/listinfo/mitgcm-devel
> >>
> >> _______________________________________________
> >> MITgcm-devel mailing list
> >> MITgcm-devel at mitgcm.org
> >> http://mitgcm.org/mailman/listinfo/mitgcm-devel
> >
> >
> > _______________________________________________
> > MITgcm-devel mailing list
> > MITgcm-devel at mitgcm.org
> > http://mitgcm.org/mailman/listinfo/mitgcm-devel
>
>
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel
More information about the MITgcm-devel
mailing list