[MITgcm-devel] wrapping up seaice_growth.F october 2010 revision

Jean-Michel Campin jmc at ocean.mit.edu
Sun Oct 17 09:19:35 EDT 2010


Hi Martin,

I don't know how things should be at the end, but it was clear to me
that those 2 options (SEAICE_GROWTH_LEGACY and USE_ORIGINAL_SBI) should
move to SEAICE_OPTIONS.h at some point. 

May be now it could be a good time to move them both to SEAICE_OPTIONS.h ?
Gael, what do you think of this ?

And regarding SEAICE_ALLOW_TD_IF, It sould be removed (with the corresponding
S/R) once we are happy with the updated code with undef SEAICE_GROWTH_LEGACY
and USE_ORIGINAL_SBI). 

Cheers,
Jean-Michel

On Sun, Oct 17, 2010 at 11:59:58AM +0200, Martin Losch wrote:
> Just a comment:
> 
> In seaice_solve4temp with have USE_ORIGINAL_SBI to decide between "legacy" and Ian's code, but in seaice_growth we have a different flag (SEAICE_GROWTH_LEGACY) to do this. So, if you want to turn off the old code, you'll have to modify two different files. Further, there is still the flag SEAICE_ALLOW_TD_IF, that is not part of seaice_growth.F (i.e. if used there will be a different number of formal/dummy parameters in the list of seaice_solve4temp.F). I am sure that this will cause a lot of confusion.
> 
> Martin
> 
> On Oct 16, 2010, at 1:12 AM, Gael Forget wrote:
> 
> > Dear all,
> > 
> > Revision 1.89 of seaice_growth.F completes the overall october 2010 revision and merging process. 
> > After sending this email I will add a summary of the 10/10 revision in tag-index.
> > 
> > If you please, it is time for you to look at the code, and put it to the test. 
> > Hopefully we won't discover too many mistakes of mine. Please let me know if you do.
> > 
> > In my view, the next phase consists in freezing seaice_growth.F (the code I mean :-) ) for a while, 
> > to take the necessary time (a week or two?) to understand and evaluate the code as it stands now. 
> > 
> > The routine has two branches (ifdef/ifndef SEAICE_GROWTH_LEGACY) that are meant 
> > to cohexist, at least for a while. For the most part they are identical. Only a 
> > few code blocks are switched ON or OFF by means of SEAICE_GROWTH_LEGACY.
> > 
> > The 'legacy' branch remains the default for now (see #define SEAICE_GROWTH_LEGACY 
> > at the top of the routine). It should give results that are very similar to v1.70.
> > This branch is meant to stay the way it is, except for potential bug fixes. 
> > 
> > So, please keep new stuff within "#ifndef SEAICE_GROWTH_LEGACY" brackets, 
> > namely within the other ('evolution') branch. No need to rush it anyway.
> > 
> > The 'evolution' branch is meant to eventually become the default, but only once it 
> > has been sufficiently tested, and I have gotten feedback -- I wont rush it. 
> > 'evolution' contains the two "_if.F" pieces. Except for that, the main deviation 
> > from 'legacy' is the treatment of pathological cases. It does, or will, 
> > ensure closed budgets. It takes place at the beginning of seaice_growth.F, 
> > right after advdiff, which is where pathological cases can come from. There is 
> > no reason why the thermodynamic code itself would lead to pathological cases. 
> > We just have to make it rigorously correct -- if the code is not already such, 
> > it will be.
> > 
> > With my set-up I plan to do few-years-long runs to test the code, using
> > 	v1.70 (legacy, pre  10/2010 revision)
> > 	v1.89 (legacy, post 10/2010 revision)
> > 	v1.89 (evolution' #undef SEAICE_GROWTH_LEGACY in seaice_growth.F)
> > 	v1.11 of seaice_growth_if.F
> > and compare results. It would be great if some of you did something like 
> > this with your own set-up of choice, and let me know how it went.
> > 
> > Cheers,
> > Gael
> > 
> > ps: Martin, I will reply to your questions in a separate email.
> > 
> > 
> > _______________________________________________
> > 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