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

[Gael Forget]

Jean-Michel, updating SEAICE_OPTIONS.h is indeed in order. Tomorrow I guess.
May be we should then replace USE_ORIGINAL_SBI with a meaningful name.
The same is true for the ones I chose, if you feel they are inadequate.

Regarding the failed lab_sea ad+mpi test, it sounds like it is probably due to my modifs. Sorry if it is.
A priori, I dont see why it would run fine in the forward and not in the adjoint. 
I will try to run lab_sea ad+mpi on my laptop today if I have time.

Martin, seaice_growth.F does not use the USE_ORIGINAL_SBI in any event. 
The way I see it, the solve4temp branches and the seaice_growth.F branches will 
eventually be chosen independently. What stands in our way is the fact that there
are extra outputs "#ifndef USE_ORIGINAL_SBI". Once the _IF stuff is removed,
we shall remove the extra outputs too, which will allow us to use either 
temperature solver branch, regardless of the seaice_growth.F branch. 

Cheers,
Gael



On Oct 17, 2010, at 9:19 AM, Jean-Michel Campin wrote:

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