[MITgcm-support] Loading a new variable

Nicolas Grisouard nicolas.grisouard at legi.grenoble-inp.fr
Tue Dec 15 08:19:59 EST 2009


Hi Jean-Michel,

I am trying to set up a simple experiment to test it. Besides the 
multiple mistakes I must be doing, I noticed an oddity in 
obcs_external_fields_load.F (and not obcs_prescribe_read.F right?) that 
is repeated a few times. Unless I'm wrong,

# ifdef ALLOW_OBCS_EAST

statements sometimes seem to be terminated by

# endif /* ALLOW_OBCS_WEST */

I don't know how these preprocessor things exactly work so I don't know 
if it makes a big difference but as in my test my forcing is coming for 
the east (and supposed to be prescribed on the western boundary), it 
might be a problem.

Otherwise, I'm working on a simple configuration to test it, I'll send 
you the files as soon as I can get it working.

Cheers,
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




More information about the MITgcm-support mailing list