[MITgcm-support] Loading a new variable

Nicolas Grisouard nicolas.grisouard at legi.grenoble-inp.fr
Tue Jan 26 10:34:46 EST 2010


Hi Jean-Michel and everyone,

I have attached to this email an "input" and "code" directories that I 
used to check the modifications you did a while ago (see the email I'm 
answering to, sorry for the delay). I tried to make it as clear as 
possible but feel free to ask any questions. It's basically:
* mode-1 internal wave forced on the western boundary
* 2D (zonal plane)
* flat bottom
* constant Brunt-Väisälä frequency
* f-plane
* sponge layer on the eastern boundary.
The parameters are typical of what could be done on a large experimental 
facility. With the parameters I give, it takes 12 mns for the code to 
run on a desktop computer (compiled with gfortran).

I'll explain a few problems I encountered in this case. Even if they are 
not related to the modification JMC made, they are quite representative 
of what I see everyday with this code. So I would be very interested in 
knowing if there is room for improvement.

So Jean-Michel, what you added works, what comes out of this test case 
is quite disappointing though. Although the input on the boundary seems 
analytically correct, there is a discrepancy on the V, W and T fields at 
point 2 (right after the western boundary). The U field looks more 
correct (although a careful observer would find odd that point 1 and 2 
in the x direction exhibit the same u-velocity). It is quite harmless in 
this case but it is something I see very often and it can be a pain in 
the neck. I didn't take care of the vertical staggering of the grid to 
prescribe U, V, W and T, maybe that's the cause. I have also been 
suggested that the pressure doesn't seem to be prescribed, and this 
might be a problem. This point (or rather its solution) is explained in 
this paper: http://dx.doi.org/10.1016/j.ocemod.2009.02.010

Second point, probably not related to the modifications you did: the V 
field looks odd to me. I don't really get why it is not symmetrical in 
approximately the two first meters after the waves are generated, 
especially as it looks like the symmetry seems to come back eventually. 
Maybe it's me who doesn't get it though.

Thank you for any suggestion I could get,
Nicolas

Jean-Michel Campin wrote:
> Hi Nicolas,
>
> I've just added some pieces of code to read the OBC wVel values
> (with useOBCSprescribe=T), for now, only in obcs_prescribe_read.F
> (i.e., without EXF).
> I don't have a good test in hand to check that it's doing the
> right thing, so if you want to give it a try,
> please let us know if you find any problem.
>
> Thanks,
> Jean-Michel
>
> On Thu, Nov 26, 2009 at 06:19:30PM +0100, Nicolas Grisouard wrote:
>   
>> OK I tried my solution, the job has been queued for quite a long time  
>> and I'll get the result tomorrow.
>>
>> Nonetheless, your solution seems more elegant. To be more specific, I  
>> force an internal wave beam on the western boundary so it really  
>> involves an OBC. About that, in both files suggested by Martin and  
>> Jean-Michel, i.e. obcs_external_fields_load.F and obcs_prescribe_read.F, 
>> there is no mentionning of any OBXw. I am wondering if there would be any 
>> conflict with the non-hydrostatic option. If there is none, I probably 
>> can force only U, V and T but the beam is usually less clean if I don't 
>> force W.
>>
>> Anyways, thanks for all the help,
>> Nicolas
>>
>> Le 26 nov. 09 à 17:06, Jean-Michel Campin a écrit :
>>
>>     
>>> Hi Nicolas,
>>>
>>> If the goal is just to add a specific forcing term,
>>> I would try to use "mypackage" with
>>> (#define MYPACKAGE_TENDENCY).
>>> and read the spatial structure only once and then compute the
>>> tendency at each time step.
>>> But if it's really related to an open-boundary problem, then
>>> I would follow Martin's suggestion. And then you could just modify
>>> obcs_external_fields_load.F (called at each time-step, but loads
>>> file only once if periodicExternalForcing is false).
>>> Cheers,
>>> Jean-Michel
>>>
>>> On Thu, Nov 26, 2009 at 11:46:38AM +0100, Nicolas Grisouard wrote:
>>>       
>>>> Hi,
>>>>
>>>> I think I tried like a year ago (not sure what the exact package was
>>>> though). I might have not gotten it right but I came to the  
>>>> conclusion
>>>> that I only had 2 options: either to set a constant forcing (which  
>>>> seems
>>>> to be te case in exp4, but which is not the case in my experiment)  
>>>> or to
>>>> reload a new file at each time step, which was nearly doubling the
>>>> computing time.
>>>>
>>>> My idea is to load the spatial stucture of the forcing once and for 
>>>> all,
>>>> like tRef, and then to apply a time propagator at each time step. The
>>>> spatial structure as no simple analytical formulation, unlike the  
>>>> time
>>>> propagator which is simply exp(iwt). Following Jody's links, I am
>>>> modifying load_ref_files.F to add a new variable and I think it  
>>>> should
>>>> work... shouldn't it?
>>>>
>>>> Nico.
>>>>
>>>> Le 26 nov. 09 à 10:36, Martin Losch a écrit :
>>>>
>>>>         
>>>>> Why don't you use the obcs package? As a simple example see exp4
>>>>> (you'll need to specify 2D fields instead of profiles, though).
>>>>>
>>>>> Martin
>>>>>
>>>>> On Nov 25, 2009, at 5:52 PM, Nicolas Grisouard wrote:
>>>>>
>>>>>           
>>>>>> Hi everyone,
>>>>>>
>>>>>> I am trying to set a quite unusual forcing on a boundary which has
>>>>>> no simple analytical expression (it has one though). I think that
>>>>>> the best option would imply loading a variable that I would have
>>>>>> defined on matlab first.
>>>>>>
>>>>>> The way I see it, I would proceed the same way I load the
>>>>>> temperature reference:
>>>>>> tRefFile='tRefvar',
>>>>>> tRefvar being a file having been created with gendata.m. I want to
>>>>>> do that but with a new variable.
>>>>>>
>>>>>> I am not used to modify the code at that level and I can't see what
>>>>>> steps happen between the file data and the definition of the
>>>>>> variable tRef, which would help me introducing my new file. Could
>>>>>> anyone give me some hints, either about the chain of files involved
>>>>>> in the definition of tRef or how to load my variable from the
>>>>>> beginning?
>>>>>>
>>>>>> Thanks!
>>>>>> Nicolas
>>>>>>
>>>>>> -- 
>>>>>> Nicolas Grisouard
>>>>>> PhD Student - ERES research group
>>>>>> Laboratoire des Ecoulements Geophysiques et Industriels
>>>>>> BP53
>>>>>> GRENOBLE CEDEX 9 FRANCE
>>>>>> tel : +33 (0) 476 825 037 - fax : +33 (0) 476 827 022
>>>>>> http://nicolas.grisouard.free.fr
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>>           
>>>> -- 
>>>> Nicolas Grisouard
>>>> PhD Student - ERES research group
>>>> Laboratoire des Ecoulements Geophysiques et Industriels
>>>> BP53
>>>> GRENOBLE CEDEX 9 FRANCE
>>>> tel : +33 (0) 476 825 037 - fax : +33 (0) 476 827 022
>>>> http://nicolas.grisouard.free.fr
>>>>
>>>>         
>>>> _______________________________________________
>>>> 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
>>>       
>> -- 
>> Nicolas Grisouard
>> PhD Student - ERES research group
>> Laboratoire des Ecoulements Geophysiques et Industriels
>> BP53
>> GRENOBLE CEDEX 9 FRANCE
>> tel : +33 (0) 476 825 037 - fax : +33 (0) 476 827 022
>> http://nicolas.grisouard.free.fr
>>
>>     
>
>   
>> _______________________________________________
>> 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
>   


-- 
Nicolas GRISOUARD
PhD Student - ERES research group
Laboratoire des Ecoulements Geophysiques et Industriels
BP 53
38041 Grenoble cedex 9 France
tel: +33 (0)476 825 037 - fax: +33 (0)476 827 022
http://nicolas.grisouard.free.fr

-------------- next part --------------
A non-text attachment was scrubbed...
Name: internal_wave_NH.tar
Type: application/x-tar
Size: 266240 bytes
Desc: not available
URL: <http://mitgcm.org/pipermail/mitgcm-support/attachments/20100126/ff32f406/attachment-0001.tar>


More information about the MITgcm-support mailing list