[MITgcm-support] MITgcm-support Digest, Vol 129, Issue 16
Pär Jansson
jansson.par at telia.com
Tue Mar 11 06:27:55 EDT 2014
Thanks Jody!
No, I didn't d apply a time-lag. That should be easily done, as I know the BT phase velocity.
Eta is flat and velocities are zero everywhere initially.
Will see if I can understand how to calculate the analytical solution to use as initial condition and how to apply it.
Thanks also for the online energy diagnostics.
Cheers!
/Per
(University of Gothenburg)
10 mar 2014 kl. 15:58 skrev mitgcm-support-request at mitgcm.org:
> Send MITgcm-support mailing list submissions to
> mitgcm-support at mitgcm.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://mitgcm.org/mailman/listinfo/mitgcm-support
> or, via email, send a message with subject or body 'help' to
> mitgcm-support-request at mitgcm.org
>
> You can reach the person managing the list at
> mitgcm-support-owner at mitgcm.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of MITgcm-support digest..."
>
>
> Today's Topics:
>
> 1. Re: Unwanted seiche caused by boundary condition on velocity
> (Jody Klymak)
> 2. issue using mdsioLocalDir with control package (Daniel Goldberg)
> 3. Re: issue using mdsioLocalDir with control package
> (Matthew Mazloff)
> 4. Re: issue using mdsioLocalDir with control package
> (Daniel Goldberg)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 9 Mar 2014 09:22:13 -0700
> From: Jody Klymak <jklymak at uvic.ca>
> To: mitgcm-support at mitgcm.org
> Subject: Re: [MITgcm-support] Unwanted seiche caused by boundary
> condition on velocity
> Message-ID: <EA584606-E992-4704-905A-F8A325E716E0 at uvic.ca>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi P?r,
>
> 1) Did you lag one end relative to the other to account for the finite propagation time of th BT wave?
> 2) Did you start with an initial condition for U,V, and Eta? If you don't, you have nothing to accelerate the flow in the interior until the BT waves from the sides propagate in, and then it takes time for it all to come into balance, ie. you get a seiche
>
> Even if you do these things, there will be a bit of a startup transient because your analytical solution won't be correct because of the form drag due to the sill.
>
> You can also force the model with a body force in exf_forcing.F. Modify the gU and gV terms.
>
> You may also want to check out my online energy diagnostics at https://github.com/jklymak/MITgcmcode if your non-linear terms will end up being large.
>
> Cheers, Jody
>
>
>
>
>
>
>
>
> On Mar 9, 2014, at 8:23 AM, P?r Jansson <jansson.par at telia.com> wrote:
>
>> Hi all!
>> I'm modeling stratified (2-layer) flow over a fjord sill in MITgcm. Focusing on barotropic and baroclinic energy flux (u'p') etc.
>> I get an unwanted surface seiche caused by the model boundary conditions, which complicates the analysis;
>> The model (2dimensional x,z) velocity boundary condition u=A*sin(t*2*pi/T_tide) is applied in both western and eastern boundary.
>> Any ideas on how to remove or reduce the seiche?
>>
>> Best regards!
>> P?r
>>
>> _______________________________________________
>> MITgcm-support mailing list
>> MITgcm-support at mitgcm.org
>> http://mitgcm.org/mailman/listinfo/mitgcm-support
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://mitgcm.org/pipermail/mitgcm-support/attachments/20140309/ee00b372/attachment-0001.htm>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 10 Mar 2014 08:55:29 +0000
> From: Daniel Goldberg <dngoldberg at gmail.com>
> To: MITgcm-support at mitgcm.org
> Subject: [MITgcm-support] issue using mdsioLocalDir with control
> package
> Message-ID:
> <CAEhdav+uM3mwrYHJb+dwJv=KmHM=--Fb5xZ6m9NetDxobx07Pw at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi there
>
> I was wondering if the mdsioLocalDir parameter has been used extensively,
> particularly when using the control and cost packages in a multiproc
> environment.
>
> I have done this and run into problems -- from what I can tell this
> parameter causes directories mdsioLocalDirXXXX to be created, where XXXX is
> the processor rank. This leads to an error though, because
> MDSREADFIELD_3D_GL (which needs to read maskCtrlC) seems to expect all
> files to be in a single directory. Is this a bug or have I configured
> incorrectly?
>
> Thanks very much
> Dan
>
> --
>
> Daniel Goldberg, PhD
> Lecturer in Glaciology
> School of Geosciences, University of Edinburgh
> Geography Building, Drummond Street, Edinburgh EH8 9XP
>
>
> em: D <dgoldber at mit.edu>an.Goldberg at ed.ac.uk
> web: http://ocean.mit.edu/~dgoldberg
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://mitgcm.org/pipermail/mitgcm-support/attachments/20140310/050a9dbe/attachment-0001.htm>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 10 Mar 2014 07:48:48 -0700
> From: Matthew Mazloff <mmazloff at ucsd.edu>
> To: <mitgcm-support at mitgcm.org>
> Subject: Re: [MITgcm-support] issue using mdsioLocalDir with control
> package
> Message-ID: <5E9AC419-3780-4594-A7A2-CCD296094C4A at ucsd.edu>
> Content-Type: text/plain; charset="windows-1252"
>
> Hello
>
> Yes, it does look like there is an inconsistency between ecco_cost_weights.F and the packing routines.
>
> For define ALLOW_PACKUNPACK_METHOD2 it should work as they both use active_read_xyz to read the mask
>
> But undef ALLOW_PACKUNPACK_METHOD2 uses MDSREADFIELD_3D_GL to read the mask?.Should we switch this?
>
> Although, glancing the code it does seem this should still work as mdsioLocalDir is attached as a prefix in MDSREADFIELD_3D_GL on line 132. What is the error message you are getting?
>
> and are you using useSingleCPUIO?
>
> Matt
>
>
>
>
> On Mar 10, 2014, at 1:55 AM, Daniel Goldberg <dngoldberg at gmail.com> wrote:
>
>> Hi there
>>
>> I was wondering if the mdsioLocalDir parameter has been used extensively, particularly when using the control and cost packages in a multiproc environment.
>>
>> I have done this and run into problems -- from what I can tell this parameter causes directories mdsioLocalDirXXXX to be created, where XXXX is the processor rank. This leads to an error though, because MDSREADFIELD_3D_GL (which needs to read maskCtrlC) seems to expect all files to be in a single directory. Is this a bug or have I configured incorrectly?
>>
>> Thanks very much
>> Dan
>>
>> --
>>
>> Daniel Goldberg, PhD
>> Lecturer in Glaciology
>> School of Geosciences, University of Edinburgh
>> Geography Building, Drummond Street, Edinburgh EH8 9XP
>>
>>
>> em: Dan.Goldberg at ed.ac.uk
>> web: http://ocean.mit.edu/~dgoldberg
>> _______________________________________________
>> MITgcm-support mailing list
>> MITgcm-support at mitgcm.org
>> http://mitgcm.org/mailman/listinfo/mitgcm-support
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://mitgcm.org/pipermail/mitgcm-support/attachments/20140310/07e3019b/attachment-0001.htm>
>
> ------------------------------
>
> Message: 4
> Date: Mon, 10 Mar 2014 14:58:16 +0000
> From: Daniel Goldberg <dngoldberg at gmail.com>
> To: mitgcm-support at mitgcm.org
> Subject: Re: [MITgcm-support] issue using mdsioLocalDir with control
> package
> Message-ID:
> <CAEhdavLuA=4p_4tFdE4vFKrW=WdkL-47r1_nj7-+8AraNOK3TQ at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Thanks Matt --
>
> It might be this useSingleCPUIO parameter that i was missing. Where is it
> set/what does it do?
>
>> From what I can infer MDSREADFIELD_3D_GL tries to read all the files
> (XXX.001.001.data, etc) from the same directory -- that is, whatever
> mdsioLocalDir is set to on that process (which differs by process rank).
> Because of mdsioLocalDir there is a different directory for each rank. Will
> useSingleCpuIO address this?
>
> Thanks
> Dan
>
>
>
>
> On Mon, Mar 10, 2014 at 2:48 PM, Matthew Mazloff <mmazloff at ucsd.edu> wrote:
>
>> Hello
>>
>> Yes, it does look like there is an inconsistency
>> between ecco_cost_weights.F and the packing routines.
>>
>> For define ALLOW_PACKUNPACK_METHOD2 it should work as they both use
>> active_read_xyz to read the mask
>>
>> But undef ALLOW_PACKUNPACK_METHOD2 uses MDSREADFIELD_3D_GL to read the
>> mask....Should we switch this?
>>
>> Although, glancing the code it does seem this should still work
>> as mdsioLocalDir is attached as a prefix in MDSREADFIELD_3D_GL on line 132.
>> What is the error message you are getting?
>>
>> and are you using useSingleCPUIO?
>>
>> Matt
>>
>>
>>
>>
>> On Mar 10, 2014, at 1:55 AM, Daniel Goldberg <dngoldberg at gmail.com> wrote:
>>
>> Hi there
>>
>> I was wondering if the mdsioLocalDir parameter has been used extensively,
>> particularly when using the control and cost packages in a multiproc
>> environment.
>>
>> I have done this and run into problems -- from what I can tell this
>> parameter causes directories mdsioLocalDirXXXX to be created, where XXXX is
>> the processor rank. This leads to an error though, because
>> MDSREADFIELD_3D_GL (which needs to read maskCtrlC) seems to expect all
>> files to be in a single directory. Is this a bug or have I configured
>> incorrectly?
>>
>> Thanks very much
>> Dan
>>
>> --
>>
>> Daniel Goldberg, PhD
>> Lecturer in Glaciology
>> School of Geosciences, University of Edinburgh
>> Geography Building, Drummond Street, Edinburgh EH8 9XP
>>
>>
>> em: D <dgoldber at mit.edu>an.Goldberg at ed.ac.uk
>> web: http://ocean.mit.edu/~dgoldberg
>> _______________________________________________
>> MITgcm-support mailing list
>> MITgcm-support at mitgcm.org
>> http://mitgcm.org/mailman/listinfo/mitgcm-support
>>
>>
>>
>> _______________________________________________
>> MITgcm-support mailing list
>> MITgcm-support at mitgcm.org
>> http://mitgcm.org/mailman/listinfo/mitgcm-support
>>
>>
>
>
> --
>
> Daniel Goldberg, PhD
> Lecturer in Glaciology
> School of Geosciences, University of Edinburgh
> Geography Building, Drummond Street, Edinburgh EH8 9XP
>
>
> em: D <dgoldber at mit.edu>an.Goldberg at ed.ac.uk
> web: http://ocean.mit.edu/~dgoldberg
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://mitgcm.org/pipermail/mitgcm-support/attachments/20140310/767dc0c6/attachment.htm>
>
> ------------------------------
>
> _______________________________________________
> MITgcm-support mailing list
> MITgcm-support at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-support
>
>
> End of MITgcm-support Digest, Vol 129, Issue 16
> ***********************************************
More information about the MITgcm-support
mailing list