[MITgcm-support] nondivergent flow advecting a tracer

钱钰坤 qianyk at mail3.sysu.edu.cn
Tue Jun 4 22:17:04 EDT 2019


Hi Neill and Edward,

Thank you very much for your help.


I’m now understanding better why there are two deltaT parameters.  This allows different deltaTs for online and offline models.  I think the deltaTtracer is somewhat redundant in my case as my velocity data are not the online outputs.  Nevertheless, I am now setting the deltaTtracer exactly the same as my deltaToffline, and the results are much better now.


It is indeed that the correction at the boundaries will be problematic because the finite differences of the streamfunction may involve land points.  To verify the divergence after the correction, I try to output the divergence diagnosed by mitgcm.  It is weird that the momHDiv diagnosis cannot be output in my offline run (I have already added vectorInvariantmomemtum=true to the data file).  I only peek at my tracer field after two years, and it looks fine even at the boundaries.  That is, there is no accumulation due to convergence at any points.


So Neill, I just don’t know how you verify your divergence after correction.  If you calculate the divergence yourself, you should take into account the factors such as the staggered c-grid, land-sea mask, partial cell etc.  The python library xmitgcm is very good at dealing with these (thanks to Ryan).


I am also curious about how does mitgcm assign the velocity data to the staggered c-grid, as they are predefined at exactly the same grid points in Aviso NC files.


Thanks again to you guys.


------------------
Best regards 


Yu-Kun Qian (钱钰坤)
Center for Monsoon and Environment Research
Department of Atmospheric Sciences
School of Environmental Science and Engineering 
Sun Yat-sen University 
No. 135 Xingang West Road, Haizhu District 
Guangzhou, 510275, P.R. China 
Tel; 020-84115227 
Email: qianyk at mail3.sysu.edu.cn




在 2019年5月31日,23:46,Neill Mackay <neill_mackay at hotmail.com> 写道:


  
Hi Yu-Kun,
 
 
 
I used the offline model to do a very similar thing to what you’re doing during my PhD (a few years ago now). I think Ed is right that the deltaToffline variable just applies to the flow field you  are prescribing, and as far as I understand all it does is determines how offline MITgcm works out the file names it is expecting for the fields, and when they are to be loaded in the course of the run. I think that the way it is designed is as if it were  reading in velocity fields previously output by an online run of MITgcm, which will have a specific naming convention based on their delta T online. So if you’re creating your own fields from altimetry (which was what I did too) you have to give them file  names that mimic the naming convention MITgcm is expecting.
 
 
 
Also as far as I remember the deltaTtracer is the one you need to get right for stability. I just kept halving it until it didn’t blow up any more! I never did figure out what deltaTclock was for.
 
 
 
Also regarding the correction of the flow fields for non-divergence, I did try this too. What do you do at the boundaries? I found that the non-divergent correction code really messed up the fields  due to the large divergence where the ocean meets land, but perhaps you’ve found a way of dealing with that.
 
 
 
 
 
Cheers,
 
 
 
Neill.
 
 
   
From: MITgcm-support <mitgcm-support-bounces at mitgcm.org> On Behalf Of Edward W Doddridge
 Sent: 31 May 2019 15:11
 To: mitgcm-support at mitgcm.org
 Subject: Re: [MITgcm-support] nondivergent flow advecting a tracer
 
 
 
 
 
Hi You-Kun, 
  
 
 
  
I’ve actually never used the offline code, so I’m not certain. I believe that deltaToffline is the time step used by the model to select the correct velocity file, while delaTtracer is the time step used to advect the tracer in the flow  field.
 
  
 
 
  
But, you might find the answers you’re looking for here: http://mitgcm.org/public/r2_manual/final/online_documents/node170.html
 
  
 
 
  
These are the example experiments using the offline code. They haven’t been translated from the old documentation yet, so if you only looked at read the docs, you might have missed them.
 
  
 
 
  
Cheers,
 
  
Ed
 
  
 
   
 
  
 
 
Edward Doddridge
 Postdoctoral researcher
 
  
Earth, Atmospheric and Planetary Sciences
 
  
Massachusetts Institute of Technology
 
   

 
 
 
  
www.doddridge.me
 
 
 
  

 
 
   
On 30 May 2019, at 12:38,  钱钰坤 <qianyk at mail3.sysu.edu.cn> wrote:
 
 
 
   
Hi Edward,
 
  
 
 
  
Thanks very much for your reminding.  After searching for the 'cfl' stuff in STDOUT, I found indeed
 
  
that the CFL condition is violated by using deltaTtracer=86400.  So I need to reduce this parameter.
 
  
 
 
  
I am now confused that how does this parameter (and deltaTClock) in data file relate to my daily
 
  
velocity data and deltaToffline=3600 set in data.off?  Can this parameter be adjusted at will without
 
  
any constraint in my OffLine Run?
 
   

 ------------------
 
   
Best regards 
 
 Yu-Kun Qian (钱钰坤) 
 Center for Monsoon and Environment Research 
 
 
Department of Atmospheric Sciences
 School of Environmental Science and Engineering 
 Sun Yat-sen University 
 No. 135 Xingang West Road, Haizhu District 
 Guangzhou, 510275, P.R. China 
 Tel; 020-84115227 
 Email: qianyk at mail3.sysu.edu.cn  
  
 
 
 
 
  
 
 
   
 
 
  
 
 
   
------------------ 原始邮件 ------------------
 
   
发件人: "Edward W Doddridge"<ewd at mit.edu>;
 
  
发送时间: 2019年5月30日(星期四) 晚上10:06
 
  
收件人: "mitgcm-support at mitgcm.org"<mitgcm-support at mitgcm.org>; 
 
  
主题: Re:  [MITgcm-support] nondivergent flow advecting a tracer
 
 
  
 
 
  
Hi Yu-Kun, 
  
 
 
  
I suspect that your timestep violates the cfl stability criterion. You should check that deltaTtracer*velocity/grid_spacing is less than 1. Ideally you’d like it to be much less than 1.
 
  
 
 
  
Cheers,
 
  
Ed
 
  
 
   
 
  
 
 
Edward Doddridge
 Postdoctoral researcher
 
  
Earth, Atmospheric and Planetary Sciences
 
  
Massachusetts Institute of Technology
 
   

 
 
 
  
www.doddridge.me
 
 
 
  

 
 
   
On 30 May 2019, at 09:48,  钱钰坤 <qianyk at mail3.sysu.edu.cn> wrote:
 
 
 
   
Hi all,
 
  
 
 
  
I am using a series of geostrophic velocity data (derived from AVISO sea surface height)
 
  
to advect a passive tracer in an offline mode.  Following the paper by Abernathey and Marshall
 
  
(2013, JGR), first I made a nondivergent correction to the original geostrophic velocity data
 
  
through Helmholtz Decomposition.  Then I used the nondivergent velocity to advect a tracer.
 
  
However, after a few timesteps the tracer field is unstable and generates very large values and
 
  
eventually contaminated the results.
 
  
 
 
  
I think there are two things need to be verified.
 
  
 
 
  
First, the correction is done correctly.  Actually
 
  
I followed the guidance by Ryan Abernathey at:
 
  
     https://github.com/rabernat/mitgcm_2D_global/blob/master/notebooks/correction.ipynb
 
  
I run the offline model first using original geostrophic velocity to dump the diagnostics of streamfunction
 
  
(psi) and velocity potential (phi).  Then I use the xmitgcm utility to calculate the nondivergent velocity as:
 
   
    u_psi = -(numpy.roll(psi, -1, axis=-2) - psi) / dyG / drF
 
  
    v_psi =  (numpy.roll(psi, -1, axis=-1) - psi) / dxG / drF
 
 
  
This code above should be modified somewhat if one uses the latest xmitgcm released a few days ago.
 
  
I did not do any mask since I think the MITgcm model will mask the velocity when run in offline mode (
 
  
I provided a bathymetry data to the model generated based on AVISO SSH land-sea mask).
 
  
 
 
  
Second, the offline model parameters (delta-t related) are correctly set.  Although I've read some emails
 
  
on this issue, I'm still not so sure how to set these parameters.  The following are my choices:
 
  
    data:      deltaTtracer = 86400,
 
  
                  deltaTClock = 86400,
 
  
    data.off:  deltaToffline = 3600,      (smaller dt for accuracy)
 
  
                  offlineForcingPeriod = 86400,    (AVISO data is daily mean)
 
  
                  offlineForcingCycle = 0,     (no need to reuse the velocity)
 
  
When using the above params, the offline model asks for velocity data whose names are: u.0.data, u.24.data,
 
  
u.48.data...  So I rename the velocity data into this convention.
 
  
 
 
  
Now I am really confused why the tracer overflows after only 4-5 timesteps (days).  Is there anything wrong
 
  
with the above two procedures?
 
   

 
 ------------------
 
   
Best regards 
 
 Yu-Kun Qian (钱钰坤) 
 Center for Monsoon and Environment Research 
 
 
Department of Atmospheric Sciences
 School of Environmental Science and Engineering 
 Sun Yat-sen University 
 No. 135 Xingang West Road, Haizhu District 
 Guangzhou, 510275, P.R. China 
 Tel; 020-84115227 
 Email: qianyk at mail3.sysu.edu.cn  
  
 
 
 
 
  
 
 
 
_______________________________________________
 MITgcm-support mailing list
 MITgcm-support at mitgcm.org
 http://mailman.mitgcm.org/mailman/listinfo/mitgcm-support
 
  
 
 
 
 
 
 
 
_______________________________________________
 MITgcm-support mailing list
 MITgcm-support at mitgcm.org
 http://mailman.mitgcm.org/mailman/listinfo/mitgcm-support
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.mitgcm.org/pipermail/mitgcm-support/attachments/20190605/1709e0e9/attachment-0001.html>


More information about the MITgcm-support mailing list