[MITgcm-support] Loading a new variable

Martin Losch Martin.Losch at awi.de
Tue Dec 15 09:14:40 EST 2009 

Hi Nicolas,

/* some text */ is just a comment, so no real problem, although for  
better readibility, these comments should be correct, thanks for  
spotting this (and it's fixed now).

Martin

On Dec 15, 2009, at 2:19 PM, Nicolas Grisouard wrote:

> 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
>
>
> _______________________________________________
> MITgcm-support mailing list
> MITgcm-support at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-support

More information about the MITgcm-support mailing list