[MITgcm-devel] [MITgcm-cvs] MITgcm/pkg/obcs CVS Commit
Gael Forget
gforget at MIT.EDU
Tue Apr 19 18:22:22 EDT 2011
Matt,
I gave it a quick try. Couldn't figure out why taf complains. However the simplest
way may be to put that piece of code in ctrl_init.F (which TAF wont see).
Cheers, g
ps: I checked in the suggested modif of pkg/smooth
On Apr 19, 2011, at 3:52 PM, Matthew Mazloff wrote:
> Hello,
>
> If I close the file TAF gives a largely benign recomputation warning as it can no longer find dunit
>
> Any suggestions on how to do this
>
> still cleaning and working on it,
> -Matt
>
>
>
>
>
>
>
>
> .
> On Apr 19, 2011, at 8:54 AM, Martin Losch wrote:
>
>> Hi Matt,
>>
>> I am fine with the code, except for maybe the reading of the mode-matrix ctrl_init_obcs_variables.F:
>> 1. the unit 117 is hard wired, that may not be portable, can we use "CALL MDSFINDUNIT( dUnit, myThid )" instead (stolen from mdsio_read_field.F), or is that too pkg-specific?
>> 2. the unit 117 is not closed
>>
>> 3. in data.ctrl, why is xx_obcs?period=9999999999.0? Do you mean "0" but that didn't work? Please try now with xx_obcs?period=0.0, it should work now.
>>
>> Martin
>>
>> On Apr 19, 2011, at 3:13 PM, Jean-Michel Campin wrote:
>>
>>> Hi Matt,
>>>
>>> I think we can start with this (but would wait for Martin's feedback).
>>>
>>> 2 little things:
>>> 1) the name of the experiment to add in verification
>>> (I prefer dir with lower case letters, so that it's ordered
>>> in the same way on all platforms).
>>> could be something with obcs_ctrl in it (similar to bottom_ctrl),
>>> but you need to decide.
>>> 2) I would be tempted to reduce even further the number of
>>> time-steps (presently 72, 24.h).
>>> Could we try to run for 6.h (18.iter) ?
>>> (does not need to be changed in MITgcm_contrib/SOSE/BoxAdj, can
>>> be done directly in verification/*/input_ad)
>>>
>>> Cheers,
>>> Jean-Michel
>>>
>>> On Mon, Apr 18, 2011 at 05:08:48PM -0700, Matthew Mazloff wrote:
>>>> Hello Martin and JMC,
>>>>
>>>> OK, so I updated
>>>> MITgcm_contrib/SOSE/BoxAdj/
>>>> and added in gradient check -- it runs for 1 day and checks gradient
>>>> on western obcs. It passes with 1-FDGRD/ADGRD < 1e-5.
>>>>
>>>> For now I believe it is just checking the temperature gradient,
>>>> however, and it should probably check the normal velocity gradient
>>>> too. It's been awhile since I used the gradient check package and
>>>> I'm having trouble remembering how to do that for obcs...I can work
>>>> on that later, or maybe one of you can fix that in
>>>> data.grdchk....its not an immediate issue though...
>>>>
>>>> Ideally I would like to see
>>>> ctrl_getobcs(n,s,e,w).F ctrl_init_obcs_variables.F and OBCS.h
>>>> merged into the main code and then the BoxAdj code, minus those 6
>>>> files of course, made into a verification experiment. Let me know
>>>> what you think
>>>>
>>>> Thanks
>>>> Matt
>>>>
>>>>
>>>>
>>>>
>>>> On Apr 18, 2011, at 3:50 PM, Matthew Mazloff wrote:
>>>>
>>>>> Hi Jean-Michel -- sorry about calling you Martin last email :o)
>>>>>
>>>>> so -- anyway, the BoxAdjoint is very simple -- but does use modes to
>>>>> control OBCS. To be most useful this code (modifications to
>>>>> ctrl_getobcs(n,s,e,w).F ctrl_init_obcs_variables.F and OBCS.h) should
>>>>> be checked into the main branch, thus minimizing code in the
>>>>> verification folder. Should I go ahead and check in this stuff (all
>>>>> mods are within a preprocessor block), or do you want me to just
>>>>> update SOSE/BoxAdj and you can incorporate it all into /verification/
>>>>> BoxAdj? How's best to proceed?
>>>>>
>>>>> Thanks
>>>>> Matt
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Apr 18, 2011, at 2:31 PM, Jean-Michel Campin wrote:
>>>>>
>>>>>> Hi Matt,
>>>>>>
>>>>>> Regarding lab_sea, it has already many things turned on,
>>>>>> so probably better not to add obcs.
>>>>>>
>>>>>> But the SOSE/BoxAdj does not look too big (64x64x8) to be turned
>>>>>> into a verification test. Are all the input files there ?
>>>>>> We would need to turn on grdchk. Anything else ?
>>>>>>
>>>>>> Cheers,
>>>>>> Jean-Michel
>>>>>>
>>>>>> On Mon, Apr 18, 2011 at 01:36:24PM -0700, Matthew Mazloff wrote:
>>>>>>> Hi Martin,
>>>>>>>
>>>>>>> I would love an obcs adjoint verification experiment. We can make
>>>>>>> a new one -- or perhaps just modify a present one...e.g. lab sea
>>>>>>> would be a good candidate. What do people prefer.
>>>>>>>
>>>>>>> As for the obcs control modes code, I have not checked it in the
>>>>>>> main branch yet... It is still in
>>>>>>> http://mitgcm.org/viewvc/MITgcm/MITgcm_contrib/SOSE/BoxAdj/code_ad/
>>>>>>>
>>>>>>> -Matt
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Apr 18, 2011, at 1:38 AM, Martin Losch wrote:
>>>>>>>
>>>>>>>> Hi Matt,
>>>>>>>>
>>>>>>>> what's the status of the verification experiment for adjoint obcs?
>>>>>>>> I cannot remember ... is the ball in my half of the playing field?
>>>>>>>> Having this experiment would help to avoid these recurring issues!
>>>>>>>>
>>>>>>>> Martin
>>>>>>>>
>>>>>>>> On Apr 18, 2011, at 7:38 AM, Matthew Mazloff wrote:
>>>>>>>>
>>>>>>>>> Hi JMC,
>>>>>>>>>
>>>>>>>>> I just updated code and am getting some odd TAF errors from your
>>>>>>>>> latest changes to obcs....not sure whats going on -- I'll let
>>>>>>>>> you know when I figure it out....or if you have any ideas please
>>>>>>>>> let me know
>>>>>>>>>
>>>>>>>>> thanks
>>>>>>>>> matt
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Apr 16, 2011, at 8:15 PM, Jean-Michel Campin wrote:
>>>>>>>>>
>>>>>>>>>> Update of /u/gcmpack/MITgcm/pkg/obcs
>>>>>>>>>> In directory baudelaire:/srv/scratch/jmc/gcm_current/pkg/obcs
>>>>>>>>>>
>>>>>>>>>> Added Files:
>>>>>>>>>> obcs_exchanges.F
>>>>>>>>>> Removed Files:
>>>>>>>>>> obcs_prescribe_exchanges.F
>>>>>>>>>> Log Message:
>>>>>>>>>> rename obcs_prescribe_exchanges -> obcs_exchanges
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> MITgcm-cvs mailing list
>>>>>>>>>> MITgcm-cvs at mitgcm.org
>>>>>>>>>> http://mitgcm.org/mailman/listinfo/mitgcm-cvs
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> 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
>>
>>
>> _______________________________________________
>> 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